codex exec on Windows: every invocation emits `failed to record rollout items: thread <uuid> not found` for the just-created session

Took a look at this — the "Limited persistence mode" hint from #18533 turns out to be a red herring for this specific symptom. EventPersistenceMode::Limited is just an event-type filter (see codex-rs/rollout/src/policy.rs); both Limited and Extended register the thread with the thread-store normally. The ThreadNotFound here is a use-after-shutdown race, not a persistence-mode skip. It's also not actually Windows-specific — the code path is platform-agnostic; I just happened to notice it on Windows because my wrapper parsed stderr.

Trace

On every codex exec, after the answer streams:

1. Exec sends Op::Shutdown (codex-rs/exec/src/lib.rs:902 → session/mod.rs:721).
2. Dispatched to handlers::shutdown (core/src/session/handlers.rs:940).
3. handlers.rs:963-965: live_thread.shutdown().await → LocalThreadStore::shutdown_thread → live_writer::shutdown_thread removes the recorder from the live_recorders hashmap.
4. handlers.rs:977-981: then sess.send_event_raw(event) is called with EventMsg::ShutdownComplete.
5. send_event_raw (session/mod.rs:1575) unconditionally calls persist_rollout_items.
6. persist_rollout_items (session/mod.rs:2687) finds self.live_thread() still Some(...) — services.live_thread is never cleared on shutdown.
7. live_thread.append_items → LocalThreadStore::live_recorder (thread-store/src/local/mod.rs:99-109) — hashmap miss — returns ThreadStoreError::ThreadNotFound.
8. session/mod.rs:2691 logs it at ERROR.

The extra twist: ShutdownComplete maps to None in rollout/src/policy.rs:event_msg_persistence_mode, so RolloutRecorder::record_items would have filtered it out anyway. But the hashmap lookup in live_writer::append_items fires before the filter runs, so we get a scary log line for an item that would have been dropped as a no-op.

Fix scope — I'd like to land the smallest correct change

Three options, in order of diff size:

1. Downgrade ThreadNotFound from error! to debug! in persist_rollout_items (~10 lines, session/mod.rs:2687-2693). Match on the error variant — ThreadStoreError::ThreadNotFound is an expected post-shutdown race, anything else stays at error!. Acts as a safety net for any post-shutdown persist, not just ShutdownComplete.

1. Emit ShutdownComplete via deliver_event_raw instead of send_event_raw (~5 lines, handlers.rs:977-981). Bypasses rollout persistence for a terminal event that's already in the no-persist list. Narrower, but only addresses the one emitter we know about.

1. Clear services.live_thread on shutdown so the Some guard in persist_rollout_items short-circuits. Requires interior mutability (services is shared via Arc), so it's a bigger structural change than warranted.

My preference is (1) — it expresses the right semantic ("ThreadNotFound after a deliberate shutdown isn't an error") and catches any other post-shutdown emitters that show up in the future. Happy to go with (2) instead if maintainers would rather keep log levels untouched.

No tests currently cover this ordering; happy to add a regression test that asserts persist_rollout_items after live_thread.shutdown() doesn't log at ERROR, if that'd help.

noticing same error in many sessions too. seems to not affect anything.

@Gusarich thanks for confirming. That's useful evidence it's not platform-specific. The symptom is benign interactively, but it has measurable impact for the automation surface this command is shaped for:

• Logged at ERROR level on 100% of codex exec runs. Wrappers that scrape stderr to detect failures (a common pattern for headless agent orchestrators) treat this as a real error. In a Claude Code subagent that wraps codex exec, the ERROR line tripped retry logic, and every delegation produced two codex exec invocations until I filtered the line in the wrapper. Roughly 2× latency and 2× quota burn (significant on ChatGPT Plus) per delegation.
• codex exec --full-auto is positioned for automation: CI pipelines, agent harnesses, scripted workflows. Deterministically printing an ERROR-level line on every successful run undermines that use case.
• Skews log analytics. Anyone monitoring Codex via structured log ingestion sees a guaranteed false-positive ERROR event per exec.

It doesn't break the visible answer, but it does break the contract that ERROR-level lines mean something went wrong, and that contract is what wrappers and dashboards rely on.

---

Validation update: I went ahead and applied option (1) on a local branch so I had a working binary for my own use (the retry-on-stderr issue is what brought me here).

On that branch:

• Original repro on Windows no longer emits the failed to record rollout items: thread <uuid> not found line at default log level. The session id printed in the banner is not referenced in any ERROR after the fix.
• New regression test core/src/session/tests.rs::persist_rollout_items_after_shutdown_does_not_log_error exercises the production sequence (live_thread.shutdown(), then persist_rollout_items(ShutdownComplete)) and asserts no ERROR line for failed to record rollout items.
• cargo fmt --check, cargo clippy -p codex-core --all-targets --no-deps -- -D warnings, and cargo test -p codex-core --lib (1510 passed, 0 failed, 4 ignored) all clean.
• Match in persist_rollout_items is exhaustive per AGENTS.md ("avoid wildcard arms"), so any future ThreadStoreError variant surfaces as a compile error rather than silently falling into the noisy error! branch.

I read docs/contributing.md and saw the invitation-only policy for external PRs, so not opening one uninvited. Posting the validation here so the next person who looks at this issue doesn't have to redo it. If option (1) is the right scope and a maintainer is open to a PR, the branch is ready to push; equally happy to hand the diff off, or to rework as option (2) (routing ShutdownComplete through deliver_event_raw so it bypasses persistence entirely) if that's preferred.

PR posted for review: https://github.com/openai/codex/pull/19630

Thanks for the bug report. This will be addressed in the next release.