Skip to content

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

Open

Description

@ywkuno

Environment

  • Date: 2026-05-05 (local timezone)
  • Platform: Codex Desktop (local session data under C:\Users\[redacted]\\.codex)

What happened

Attempting to resume a thread failed with a missing rollout file error.

This was not an isolated thread: all historical thread payloads appear to be missing from disk while metadata rows remain.

Findings

  • state_5.sqlite contains 91 rows in threads.
  • session_index.jsonl contains 1 entry.
  • Only 1 rollout-*.jsonl file exists in session storage.
  • 90 other thread IDs in threads point to missing rollout_path files.
  • The broken path reported in the failure is:
    • C:\Users\[redacted]\.codex\sessions\2026\05\05\rollout-2026-05-05T21-23-50-<redacted>.jsonl

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).

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 5, 2026
  2. ywkuno commented on May 5, 2026

    @ywkuno
    Author

    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.

  3. ywkuno commented on May 5, 2026

    @ywkuno
    Author

    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.

  4. ywkuno commented on May 5, 2026

    @ywkuno
    Author

    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.

  5. ywkuno commented on May 5, 2026

    @ywkuno
    Author

    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.

  6. dominikkociecki commented on Aug 7, 2026

    @dominikkociecki

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions