Nightly session restore fails for Codex: pane returns as bare shell, resume binding never persisted (0.64.17-nightly)

[austinywang]

What happened

Session restoration on the nightly channel failed to bring back a running Codex session. Reported by the user on the cmux Mac mini dogfood machine on 2026-07-10 (~15:44 local), verbatim:

nightly session restoration just failed for me for codex

The Codex pane did not come back as a resumed Codex session; affected nightly workspaces show bare ~ shells and at least one dead panel (ttyName: null) instead.

Environment

• cmux NIGHTLY 0.64.17-nightly.2906518677101 (bundle com.cmuxterm.app.nightly)
• Most recent nightly relaunch: 2026-07-10T03:37:08Z (Jul 9, 20:37 local), pid 40128, still running at report time
• macOS Darwin 25.5.0, machine user cmux
• Stable cmux 0.64.17 (com.cmuxterm.app) running side-by-side on the same machine/user — relevant because parts of ~/Library/Application Support/cmux/ are shared between the two instances (see below)
• Note: the report came ~19h after that relaunch. If the failure the user observed happened today, it may have gone through Reopen Previous Session rather than app relaunch; both funnel into session restoration and both need checking.

Evidence collected from the machine (2026-07-10)

1. The pre-relaunch snapshot contains nothing that could resume Codex. ~/Library/Application Support/cmux/session-com.cmuxterm.app.nightly-previous.json (rotated at the Jul 9 20:37 relaunch) records 17 workspaces / 21 terminal panels. Every terminal panel is persisted as a bare shell (title: "~", workingDirectory: /Users/cmux) except two ✳ Claude Code panes. No panel carries any agent/resume information.
2. The session-file schema has no agent fields at all. Panels persist only type, title, ttyName, stableSurfaceId, terminal.workingDirectory, terminal.isRemoteTerminal (+ browser state). There is no launchCommand / resume-binding field, so agent resume must depend entirely on the out-of-band binding store keyed by ttyName (Agent session↔pane bindings scramble across relaunch (keyed on ephemeral ttyName, not stable pane UUID) #7750).
3. ttyName keys are demonstrably unreliable in these snapshots. In the current nightly session file, ttys011 is recorded on three different panels across three workspaces; the previous file has it on two. macOS recycles tty names, and two cmux instances (stable + nightly) allocate from the same pool.
4. Shared un-namespaced state across instances. Session files are per-bundle-id, but ~/Library/Application Support/cmux/search.db (Session Index) is shared by stable and nightly. If resume bindings (or anything keyed by ttyName) live in shared state, the two instances can stomp each other.
5. The restore path emits zero diagnostics. ~/Library/Logs/cmux/startup-com.cmuxterm.app.nightly.log contains detailed app.init.* / appDelegate.* events for the Jul 9 relaunch but no events matching restore/resume/binding/codex (grep -icE "restor|resume|codex|agent|binding" → 0). Restoration failures currently cannot be triaged from logs at all.
6. Current live nightly session shows a workspace (A6D48E98) with a panel whose ttyName is null and generic Terminal titles — consistent with restore producing dead/blank terminals.

Hypotheses to root-cause (in likelihood order, to be verified)

• Capture-side loss: the codex pane's resume binding was never persisted (or was overwritten) before/at quit, so restore had nothing to resume — consistent with evidence 1–4.
• Restore-side binding mismatch: binding exists but lookup by recycled/duplicated ttyName misses or misroutes it (Agent session↔pane bindings scramble across relaunch (keyed on ephemeral ttyName, not stable pane UUID) #7750, Claude auto-resume can write a session's resume binding to the wrong workspace after restored TTY cache drift #7391), possibly aggravated by the stable instance sharing the tty namespace and shared state.
• Codex-side failure: restore did run codex resume <id> and codex failed ("No saved session found", Session restore intermittently fails: codex resume <id> reports "No saved session found" and drops to bare shell #6209; sqlite lock, Codex resume: transient state_5.sqlite lock fails the launch and drops the terminal to ~ (no retry, working dir lost) #5557) and the pane fell back to a bare shell — then the next periodic save persisted the bare shell, erasing the evidence.

Related issues

#6209 (codex resume "No saved session found" → bare shell), #3499 (codex resume ID lost after restart), #7750 (bindings keyed on ephemeral ttyName scramble across relaunch), #7391 (claude resume binding written to wrong workspace after restored TTY cache drift), #5802 (autoResumeAgentSessions gate never resumes), #5557 (codex resume sqlite lock), #6194 (claude twin of #6209), #4782 (multiple agent sessions not restored).

Definition of done

• Root cause identified for how a live Codex session's restoration is lost across a nightly relaunch (capture vs restore vs codex-side), with the failing path covered by a regression test committed before the fix.
• Fix makes Codex sessions restore reliably across relaunch, including with a second cmux instance (stable + nightly) running under the same user.
• Session-restore decisions (bindings found/missing, resume command issued, per-panel outcome) emit events into the startup log sink so the next report like this is triageable from logs.