You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Data loss: resumed-thread errors due missing rollout JSONL files (state still has threads, files gone) #21196
This appears to be a case where durable chat payloads were removed without corresponding metadata cleanup, causing previously available history to become unreachable.
Expected behavior
Rollout files should not disappear silently while metadata remains.
If files are missing, the system should provide recovery/repair guidance and avoid orphaning threads.
Severity
High (multiple days of user history become inaccessible).
Additional context from latest report: user says this happened while ~3 threads were still active. I rechecked local storage and confirmed the same pattern: hreads table has 91 entries, but only 1 rollout file exists on disk, meaning 90 JSONL payloads are missing. This isn’t a single missing thread; it’s effectively all historical chat payloads unavailable while metadata remains. No filesystem search in .codex or nearby AppData/Documents paths found backups for those rollout files.
Follow-up from user backup check: both desktop backup folders are state-only (state_5.sqlite + shm/wal), contain no rollout jsonl payload files. Thread rows in backup DBs: 125/126, with 0 existing rollout files for all referenced paths right now. First folder also has .codex-global-state.json (app metadata), not chat payload.
Update: checked plugin recovery path. .codex still contains plugin framework files (cache/runtime runtime bundles, plugin directories, and marketplace catalog), but UI shows all plugins as not installed and config.toml only has 4 enabled plugin entries (documents/spreadsheets/presentations/browser-use). No other plugin-install-state files found in .codex that could reconstruct previous install list. This suggests installed plugin state was likely reset/disconnected even though binaries and marketplace manifest remain intact.
Additional redacted forensic findings after correlating Codex Desktop logs, Codex app-server logs, surviving state DBs, and Windows event timing. All times below are UTC; user/profile paths, project names, rollout filenames, thread IDs, and raw chat/log contents are intentionally withheld.
Observed sequence:
Around 2026-05-05T13:45:40Z-13:45:53Z, multiple Codex threads were still active and receiving/streaming model responses.
At 2026-05-05T13:45:48Z, Codex Desktop sent windowsSandbox/setupStart to the app server.
At 2026-05-05T13:45:50Z-13:45:55Z, codex-windows-sandbox-setup.exe ran. The sandbox log records sandbox-user setup, firewall rule setup, and a read-acl-only mode: applying read ACLs pass. That pass touched user-profile app-state paths outside the active project, plus LocalAppData; exact paths withheld because they reveal private local app usage.
At 2026-05-05T13:45:55Z, Codex emitted windowsSandbox/setupCompleted.
By 2026-05-05T13:46:02Z, the Codex app-server process had restarted/changed process identity.
Starting at 2026-05-05T13:46:04Z, Codex Desktop repeatedly attempted thread/resume and failed with failed to resolve rollout path ... The system cannot find the path specified. (os error 3) for active/recent threads.
The desktop log also records app_server_restart_recovery_failed for at least one active conversation immediately after these resume failures.
The user-initiated OS reboot happened later, after the sessions were already frozen/missing-rollout failures were visible. So the reboot appears to be a response to the failure state, not the initiating cause.
Scope / persistence findings:
Surviving state/log DBs still contain thread metadata and enough log events to reconstruct a readable archive, but the original rollout JSONL payload files are missing from the expected sessions tree.
Deeper reconstruction across surviving DB/log sources found hundreds of thread records/events, while only one original rollout file remained in the current sessions tree at the time of inspection.
The plugin UI/state also appeared reset/disconnected after the incident, even though some plugin/cache/runtime files still existed on disk.
No obvious user shell command deleting the Codex state/session directories was found in PowerShell history. This does not prove no process deleted them, but it makes a manual shell deletion unlikely based on available evidence.
Why this looks Codex-triggered:
The first confirmed failures occur immediately after the Codex Desktop sandbox setup event and app-server restart/recovery path, before the OS reboot. The critical pattern is: active sessions running -> windowsSandbox/setupStart / sandbox setup -> app-server restart -> repeated thread/resume missing-rollout errors -> recovery failure -> user reboot.
Suggested areas to investigate:
Whether Windows sandbox setup or app-server restart recovery can delete, move, reinitialize, or lose visibility of .codex/sessions, plugin state, memories, or adjacent user-profile app-state paths.
Whether the read-acl-only sandbox setup path is guaranteed non-destructive and properly scoped.
Whether app-server restart recovery handles missing rollout files defensively, especially when state DB rows still reference those rollouts.
Whether Codex should snapshot or integrity-check rollout/session storage before sandbox setup/app-server restart recovery.
Whether missing rollout files can be recoverable from logs_2.sqlite or another durable store instead of making the conversation unrecoverable.
I can provide private evidence bundles or exact redacted-to-unredacted mappings through a private support channel, but I do not want to post raw logs or full local paths publicly because they contain private chat/project/account data.
Same signature at larger scale on Windows: 417 of 431 threads lost on 2026-08-06,
thread index in state_5.sqlite intact, rollout files gone, no error logged at the
time of deletion. Full write-up with timestamps and eliminated causes: #37419
Activity
ywkuno commentedon May 5, 2026
Additional context from latest report: user says this happened while ~3 threads were still active. I rechecked local storage and confirmed the same pattern: hreads table has 91 entries, but only 1 rollout file exists on disk, meaning 90 JSONL payloads are missing. This isn’t a single missing thread; it’s effectively all historical chat payloads unavailable while metadata remains. No filesystem search in .codex or nearby AppData/Documents paths found backups for those rollout files.
ywkuno commentedon May 5, 2026
Follow-up from user backup check: both desktop backup folders are state-only (state_5.sqlite + shm/wal), contain no rollout jsonl payload files. Thread rows in backup DBs: 125/126, with 0 existing rollout files for all referenced paths right now. First folder also has .codex-global-state.json (app metadata), not chat payload.
ywkuno commentedon May 5, 2026
Update: checked plugin recovery path. .codex still contains plugin framework files (cache/runtime runtime bundles, plugin directories, and marketplace catalog), but UI shows all plugins as not installed and config.toml only has 4 enabled plugin entries (documents/spreadsheets/presentations/browser-use). No other plugin-install-state files found in .codex that could reconstruct previous install list. This suggests installed plugin state was likely reset/disconnected even though binaries and marketplace manifest remain intact.
ywkuno commentedon May 5, 2026
Additional redacted forensic findings after correlating Codex Desktop logs, Codex app-server logs, surviving state DBs, and Windows event timing. All times below are UTC; user/profile paths, project names, rollout filenames, thread IDs, and raw chat/log contents are intentionally withheld.
Observed sequence:
2026-05-05T13:45:40Z-13:45:53Z, multiple Codex threads were still active and receiving/streaming model responses.2026-05-05T13:45:48Z, Codex Desktop sentwindowsSandbox/setupStartto the app server.2026-05-05T13:45:50Z-13:45:55Z,codex-windows-sandbox-setup.exeran. The sandbox log records sandbox-user setup, firewall rule setup, and aread-acl-only mode: applying read ACLspass. That pass touched user-profile app-state paths outside the active project, plusLocalAppData; exact paths withheld because they reveal private local app usage.2026-05-05T13:45:55Z, Codex emittedwindowsSandbox/setupCompleted.2026-05-05T13:46:02Z, the Codex app-server process had restarted/changed process identity.2026-05-05T13:46:04Z, Codex Desktop repeatedly attemptedthread/resumeand failed withfailed to resolve rollout path ... The system cannot find the path specified. (os error 3)for active/recent threads.app_server_restart_recovery_failedfor at least one active conversation immediately after these resume failures.Scope / persistence findings:
Why this looks Codex-triggered:
The first confirmed failures occur immediately after the Codex Desktop sandbox setup event and app-server restart/recovery path, before the OS reboot. The critical pattern is: active sessions running ->
windowsSandbox/setupStart/ sandbox setup -> app-server restart -> repeatedthread/resumemissing-rollout errors -> recovery failure -> user reboot.Suggested areas to investigate:
.codex/sessions, plugin state, memories, or adjacent user-profile app-state paths.read-acl-onlysandbox setup path is guaranteed non-destructive and properly scoped.logs_2.sqliteor another durable store instead of making the conversation unrecoverable.I can provide private evidence bundles or exact redacted-to-unredacted mappings through a private support channel, but I do not want to post raw logs or full local paths publicly because they contain private chat/project/account data.
dominikkociecki commentedon Aug 7, 2026
Same signature at larger scale on Windows: 417 of 431 threads lost on 2026-08-06,
thread index in state_5.sqlite intact, rollout files gone, no error logged at the
time of deletion. Full write-up with timestamps and eliminated causes: #37419