Engine health: The engine keeps failing to save session conversations to this project's memory — the session records could...

[StarshipSuperjam]

The engine opened this item itself — you didn't create it.

What this is. The engine watches the health of its own machinery — the tools and checks that help run your project, and it noticed something it is tracking here so it stays visible. This is not a problem with your product, and the engine will never open or close an item you created — only its own.

What it noticed. The engine keeps failing to save session conversations to this project's memory — the session records could not be read. Nothing in the project is lost, but those conversations won't be recallable later. This usually means the AI runtime changed how it stores session records; the fix arrives as an engine update (ask me to check for one, or watch the engine's releases). Until then it will keep working from what it already remembers.

What happens next. Usually nothing right now. When a session next works on the engine it can prepare a fix for you to review and merge, the same way you already do — the engine never changes anything in your project on its own. This is a flag, not a repair: it stays visible until the underlying problem is resolved. If it lingers and you want it sorted sooner, just say so.

First noticed 2026-07-18T13:59:27Z; last reconfirmed 2026-07-27T03:56:27Z.

[StarshipSuperjam]

Engine note — investigated, and hardened in #610 (pending your merge).

What I found when I looked into this: capture is not currently failing. Every Codex session transcript on disk — 113 of them, spanning 2026-07-07 through today — is read cleanly right now. The degraded window that first raised this flag (2026-07-18) has passed; the likely cause was transient (a transcript format that has since rolled off, or a stray file handed to capture that correctly-but-noisily refused). I could not reproduce a live break.

The real weakness this flag exposed is that when capture did refuse a transcript, it recorded only "couldn't read it" with no reason — which is exactly why this item wasn't actionable. #610 fixes that: a refusal now records a small, content-free note of which check refused it and the structural shape it saw (record/type names and a count — never any of your conversation text), so the next time a format drifts, it says what changed. It also adds secret-scrubbing at capture as part of the same slice.

On closing this: I've left it open rather than force-closing it, because the underlying dependency (an external transcript format the engine doesn't control) is a standing one, not "fixed forever." Once #610 merges and capture keeps reporting healthy, this can be closed — tell me if you'd like me to close it then, or leave it as a standing watch.