Codex can print a session ID but fail to persist any resumable local session artifacts after early transport failure

What version of Codex is running?

codex-cli 0.114.0

Which model were you using?

gpt-5.4

What platform is your computer?

Linux (Crostini container), with Zellij 0.43.1 in regular use

What issue are you seeing?

Codex CLI can print a session ID for a run, but if transport fails early enough, no resumable local session artifacts are written.

In the failing case, Codex displayed a session ID:

019d2845-fe06-7ad0-abb4-dd16b28f501f

But afterward there was:

• no matching row in ~/.codex/state_5.sqlite
• no matching rollout file under ~/.codex/sessions/

So the session appeared real/recoverable, but there was nothing local to resume.

I reproduced a contrasting success case on the same machine:

019d284a-9d34-7540-9633-2617aaa1a3cf

That successful run did create both:

• a thread row in ~/.codex/state_5.sqlite
• a rollout JSONL in ~/.codex/sessions/...

This suggests Codex can expose a session ID before local persistence is actually committed.

What steps can reproduce the bug?

I reproduced it with a minimal non-interactive run:

codex exec --color never -C /path/to/repo -o /tmp/codex-canary.out 'Reply with exactly: canary-ok'

Observed failing pattern:

1. Start codex exec
2. Codex prints a session ID
3. Transport fails very early during connection setup
4. After exit, check local persistence:

• no thread row for that session ID in ~/.codex/state_5.sqlite
• no rollout file for that session ID in ~/.codex/sessions/

In my reproduced failure, transport errors included websocket connection failures and fallback/reconnect attempts before the run died.

What is the expected behavior?

One of these should happen:

• Codex persists the session before exposing the session ID
• Codex clearly marks the session as non-persisted/non-recoverable
• Codex creates at least a minimal persisted local record for the failed run

A displayed session ID should not imply resumability when no local session artifacts exist.

Additional information

Environment details:

• Codex CLI: 0.114.0
• Model: gpt-5.4
• Platform: Linux (Crostini container)
• Terminal multiplexer: Zellij 0.43.1

Validation details:

• ~/.codex/state_5.sqlite passed PRAGMA integrity_check
• ~/.codex/logs_1.sqlite passed PRAGMA integrity_check
• successful and failing cases were reproduced on the same machine
• local wrapper does not change CODEX_HOME, HOME, or XDG state paths

Local mitigations I added after reproducing this:

• a wrapper warning when a session-producing Codex run exits without any new or updated persisted session artifacts
• a lightweight audit command to compare latest thread state, rollout files, and planning timestamps
• a canary command that runs a minimal codex exec and fails if no persisted session update is detected

Those mitigations are local diagnostics/workarounds only; they do not fix Codex itself. I can share the exact wrapper/audit/canary logic if that is useful.

Potential fix directions upstream:

• persist a minimal local session/tombstone record before displaying a session ID
• delay displaying the session ID until local persistence succeeds
• explicitly mark startup-failure session IDs as non-persisted / non-recoverable
• ensure failed startup paths still leave enough local state for history/audit/debugging

If this issue is useful and the Codex team wants a PR, I can provide the local implementation details or prepare a targeted change by invitation.