[Windows] Threads stuck on "Waiting for worktree setup…", app auto-quits: projector rejects own token_count record (`invalid type: map, expected f64`) and cursor desyncs (`expected ordinal 10, got 11`)

What version of the Codex App are you using?

• Codex Desktop 26.901.4073.0 (Microsoft Store MSIX), native Windows x64 (build 10.0.26200), PowerShell as default shell
• Bundled app-server: codex-cli 0.145.0-alpha.18

What subscription do you have?

Plus

What issue are you seeing?

Since updating to 26.901.4073.0, new threads intermittently get stuck forever on "Waiting for worktree setup…" / "Starting your task" even when the run target is Local, and sometimes the app closes itself without any crash report. The stuck state is thread-correlated (first conversation may work, a later one sticks; sometimes the very first one sticks) and survives app restarts.

Observable symptoms, all verified from ~/.codex/logs_2.sqlite, state_5.sqlite and the rollout file:

1. The composer is disabled and the user_input never reaches the app_server. The stuck thread exists only as an empty shell: a threads row with has_user_event=0, model=NULL, and no rollout file written. So this is not the model/backend being slow — the UI state machine refuses to dispatch the message.

2. The paginated history projector rejects the thread's own token_count record, then the projection cursor desyncs and every later record is rejected too:

   [codex_thread_store::local::thread_history_materialization] WARN
   skipping rejected rollout line while projecting
   "C:\Users\<me>\.codex\sessions\2026\09\04\rollout-2026-09-04T23-25-24-01a06d06-....jsonl":
   invalid type: map, expected f64 at line 1 column 846
   

   The rejected line is ordinal=10, type=event_msg, payload.type=token_count, exactly 846 bytes (so the reported column points at end-of-line). It contains the new rate_limits structure written by this same build:

   "rate_limits":{"limit_id":"codex","limit_name":null,"primary":{"used_percent":20.0,"window_minutes":300,"resets_at":1788544770},"secondary":{"used_percent":3.0,"window_minutes":10080,"resets_at":1789131570},"credits":{"has_credits":false,"unlimited":false,"balance":"0"},"individual_limit":null,"spend_control_reached":null,"plan_type":"plus","rate_limit_reached_type":null}
   

   All 12 lines of the rollout parse as valid JSON independently — the file is not corrupt; the projector schema just doesn't match what the writer produces.

3. After the rejection the projection cursor desyncs and the turn can never be persisted:

   [codex_thread_store::local::live_writer] WARN
   failed to project durable rollout for 01a06d06-...: thread-store internal error:
   thread history projection for 01a06d06-... expected ordinal 10, got 11
   

   The following task_complete (ordinal 11) is rejected as well, so the turn never materializes even though the model call itself completed fine (token usage 22672 in / 12 out is logged).

4. While stuck, the app_server log floods with app/list → app/list/updated (targeted_connections=0) plus a new codex_http_client::custom_ca HTTP client per request, hundreds of times per minute. Eventually the app_server process terminates silently (no Windows Application Error, no WER crash entry, no panic in logs — only generic MoAppHang AppHang reports for the UI earlier in the day), and the desktop window closes by itself.

5. Enabling/disabling user MCP servers changes the timing/probability but not whether it happens: it reproduced with all user MCP servers enabled, with only one enabled, and with all of them disabled.

Steps to reproduce

Not fully deterministic, but it reproduced many times within a single day on this build:

1. Codex Desktop 26.901.4073.0 on Windows, PowerShell shell (note: every thread logs Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell).
2. Start new conversations (target = Local) and send short messages.
3. Intermittently, a thread sticks on "Waiting for worktree setup…". The stuck thread's rollout is either missing or contains a token_count record that the projector rejects with invalid type: map, expected f64, followed by expected ordinal 10, got 11 for the rest of the session.
4. After minutes the app either recovers the stuck turn or the app_server dies silently and the window closes.

Expected behavior

The paginated history projector should tolerate volatile telemetry fields written by its own writer (e.g. rate_limits), and the projection cursor should resynchronize after a rejected record instead of rejecting all subsequent records including task_complete.

Suggested fix

• Lenient/untagged deserializer for volatile fields such as rate_limits (same family as #41276: invalid type: map, expected f64).
• Auto-resync of the projection cursor after a skipped record (closely related to #38792).
• A supported repair/rebuild-projection command so users don't have to hand-edit SQLite.

Related issues

• #41276 — same projector error string, different field (legacy duration objects)
• #38792 — projection cursor desynchronization is not automatically repaired
• #40253, #19500 — stuck on "Waiting for worktree setup" / first message
• #35485, #42005 — node_repl process leaks observed in the same sessions but likely unrelated to this root cause

Happy to provide the full 12-line minimal rollout sample and additional log excerpts if useful.

Start with the codex_thread_store::local::thread_history_materialization and live_writer entry points, then inspect the rejected rollout JSONL record and the related SQLite projection state. Reproduce the token_count deserialization failure and cursor ordinal mismatch; done means valid records continue projecting, the turn materializes, and the app no longer remains stuck on worktree setup.