Data loss: resumed-thread errors due missing rollout JSONL files (state still has threads, files gone)

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: https://github.com/openai/codex/issues/37419