Resume Codex sessions by name, days later.

Codex exposes two ways to continue prior work. The CLI accepts codex exec resume, and the app-server protocol accepts a resumeThread call against a known thread id. Both require you to have kept the thread id from last time. That is the part that usually goes missing — the id scrolls past in a JSON stream, the terminal closes, and the thread becomes unreachable even though the rollout is still on disk.

Muster's Codex adapter parses the --json event stream specifically to capture thread_id, and stores it on the session record next to your messages, recalled memories, and token usage. When you later run muster chat --continue work, the stored id is passed straight back into Codex's resume path. If Codex reports that the thread is gone — the adapter recognises "no rollout found", "unknown thread", and the equivalent session-not-found phrasings — Muster starts a fresh thread rather than failing the run, and carries your own session history forward regardless.

That distinction is worth stating plainly, because it is where a lot of "session memory" claims quietly overstate themselves: Muster's session record is the durable thing; the Codex thread is an optimisation on top of it. If the provider-side rollout expires, you lose the backend's internal context, not your history, your scoped memory, or your ledger.

What comes back with the session

• Your messages. Stored locally and replayed as context, independent of any provider's retention policy.
• Scoped memory. Recalls are filtered by the lanes the session is entitled to see — tenant, workspace, user, role, session — so continuing an old session does not widen its access.
• The token ledger. Usage accrues against the session, including replay-waste flags when a continuation is resending far more history than it needs.
• Observed file changes. If the run touched a repository, the change set was derived from git and the filesystem rather than from Codex's patch notifications — which, measured live, fired zero times across five runs.

Keeping continuations cheap

The naive way to continue a session is to resend the whole transcript every turn. It works, and it is why long agent threads get expensive out of proportion to what they are doing. Muster measures this on a deterministic five-scenario benchmark of 170 turns: replay-everything sends 875.8k tokens where Muster sends 355.2k, a 59.4% reduction, rising to 62.7% on the longest thread. No model is called during that benchmark — reproduce it with muster benchmark.

The practical consequence for resumed sessions is that a fifty-turn thread stays workable. The ledger shows what each continuation actually cost, and flags the runs where replay overhead dominated, so an expensive session is visible before the invoice rather than after it.

Codex is a runtime, not the product

Muster treats Codex as one adapter behind its own contract, alongside a native runtime, Claude Code and Pi. Sessions, memory scoping, the token ledger, and the observed file-change stream sit above the runtime boundary, so switching backends mid-project does not throw away the record. muster runtime doctor checks that the Codex CLI is reachable and correctly configured before you depend on it.

This also means the audit story does not change when the backend does. Whichever runtime executed the turn, the file-change evidence came from watching the workspace, and the receipt for it reproduces byte-identically on a different machine.

How observed file changes work → Read the docs →