Skip to content

bug: Local sessions persist in filesystem but disappear completely from codex resume --all and Desktop Sidebar (SQLite index mismatch) #28068

Open
Open
bug: Local sessions persist in filesystem but disappear completely from codex resume --all and Desktop Sidebar (SQLite index mismatch)#28068
Labels
CLIIssues related to the Codex CLIappIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@Atletico1999
Atletico1999
opened on Jun 13, 2026

What issue are you seeing?

Historical conversation sessions have completely disappeared from both the Codex Desktop App sidebar and the codex resume --all command line utility.

However, our debugging reveals a critical synchronization contradiction based on the following verified facts:

  1. Data Assets Intact: Both the session-index.json and the sessions directory still physically exist with all historical session files intact under C:\Users\Administrator\.codex\.
  2. --all Discrepancy: Running codex resume --all returns empty or only displays newly created test sessions, completely failing to recognize the historical .jsonl files in the subdirectory.
  3. ID Passthrough Works: If I manually extract a 36-character UUID from the first line of any raw .jsonl file, running codex resume <Session_ID> works perfectly and successfully restores the conversation history.
  4. Index Regeneration Failure: If I delete session-index.json, state_5.sqlite, state_5.sqlite-shm, and state_5.sqlite-wal, and then relaunch Codex, the state_5.sqlite, state_5.sqlite-shm, and state_5.sqlite-wal files are regenerated, but session-index.json is NOT re-created. The application completely fails to back-scan the historical files, leaving the sidebar entirely empty (except for the active test session).

What steps can reproduce the bug?

We performed a series of rigorous test cases to isolate the bug. Here are the exact steps and results:

Test Case A: Direct Resume and Exit

  1. Extract a valid historical ID from ~/.codex/sessions/.
  2. Run codex resume <Session_ID> to enter the conversation successfully.
  3. Type /exit immediately to quit the session.
  4. Run codex resume --all.
  • Result: The session does not appear in the list. It is still hidden.

Test Case B: Content Injection via Placeholder (Short Text)

  1. Enter the session via codex resume <Session_ID>.
  2. Input a dot . as a placeholder message and press Enter.
  3. Type /exit to quit.
  4. Run codex resume --all.
  • Result: The session still does not appear in the list.

Test Case C: Content Injection via Real Conversation (Long Text)

  1. Enter the session via codex resume <Session_ID>.
  2. Input a long, realistic human conversational sentence (e.g., a multi-word prompt) to trigger a full model response, ensuring an active interaction event occurred.
  3. Type /exit to quit.
  4. Run codex resume --all.
  • Result: Even after a successful long-text interaction and graceful exit, the session still fails to register back into the --all list or the desktop sidebar. It remains completely invisible unless called explicitly by its absolute ID.

What is the expected behavior?

  1. When state_5.sqlite is missing or regenerated, the Codex background daemon should automatically deep-scan the ~/.codex/sessions/ directory, parse all existing local .jsonl files, and properly rebuild the global index database.
  2. Manually resuming an existing session via codex resume <Session_ID>—regardless of whether it's an immediate exit, a short placeholder input, or a long-text conversation—should instantly force the background database to register or update that session's metadata into the active index (state_5.sqlite) so that it becomes visible globally.

Additional information

  1. Environment: Windows 11 (Root path: C:\Users\Administrator\.codex)
  2. Core Discovery: This issue highlights a severe regression in the local database routing and event persistence layers. The SQLite indexing mechanism seems to actively ignore or filter out historical local files on startup and refuses to commit them back to the global state database even after explicit physical interaction and write events occur during a manual resume.

Activity

  1. Atletico1999
    added
    bugSomething isn't working
    on Jun 13, 2026
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    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 Jun 13, 2026

  3. github-actions commented on Jun 13, 2026

    @github-actions
    github-actionsBot
    on Jun 13, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  4. Necmttn commented on Jun 21, 2026

    @Necmttn
    Necmttn
    on Jun 21, 2026

    The recovery path should be able to rebuild a read-only session index from the JSONL files.

    Each rebuilt row can carry session id, file path, parsed first/last timestamp, cwd/title if found, file mtime, parser version, and parse status. A malformed file should mark one row degraded, not prevent the sidebar/resume list from seeing the rest.

    If direct resume by id works, the file set is still a valid source of truth.

    Generated with ax.

  5. turismys commented on Jun 26, 2026

    @turismys
    turismys
    on Jun 26, 2026

    I fixed it successfully

    None of the suggested fixes in this issue worked for me (clearing caches, reinstalling the app, etc.).

    My Codex installation had been configured to use a custom gateway (I was using a reseller’s server connected to OpenRouter).

    My original ~/.codex/config.toml contained:

    model_provider = "gateway"
    model = "claude-opus-4.8"
    [model_providers.gateway]
    name = "Gateway"
    base_url = "http://45.136.205.7:3188/v1"
    wire_api = "responses"
    env_key = "OPENAI_API_KEY"
    requires_openai_auth = false
    supports_websockets = false

    I edited it by changing:

    model_provider = "openai"
    model = "gpt-5.5"

    and commented out the entire [model_providers.gateway] section.

    Additionally, I downloaded and installed the previous Codex Desktop build:

    https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.602.71036.zip

    After doing this:

    • all my chats reappeared;
    • the endless reconnect loop stopped;
    • Error 1006 disappeared;
    • Codex started working normally again.

    I’m not sure which of these two changes actually fixed the issue (the configuration change, the older build, or the combination of both), but this is what worked in my case.

  6. sunkhx commented on Jul 17, 2026

    @sunkhx
    sunkhx
    on Jul 17, 2026 – with ChatGPT Codex Connector

    Adding a current Windows data point from the post-merge ChatGPT/Codex desktop builds. This still reproduces on the latest update available to this machine.

    Environment:

    • Windows 11 x64
    • Previously affected Desktop package: 26.707.12708.0
    • Still affected after updating to: 26.715.2305.0
    • Local Codex home contains 64 active session JSONL files and 39 archived session JSONL files

    Observed behavior:

    • The project sidebar shows No chats for historical projects.
    • The app-level thread listing with limit: 49 returns only 2 recent threads, despite 64 active rollout files being present.
    • Historical rollout JSONL files are readable; extracting an old thread ID and navigating/resuming by that exact ID successfully opens the complete conversation.
    • Updating from 26.707 to 26.715 did not trigger a back-scan or rebuild of the historical thread index.

    Backup-first workaround attempts that did not restore the sidebar on these builds:

    • Rebuilt .codex-global-state.json -> projectless-thread-ids to include all recoverable active IDs (95 IDs after preserving existing entries).
    • Added/pinned every active thread through the app API (64 pinned IDs currently persisted).
    • Fully quit and restarted the app.
    • Re-tested listing with limit: 49; it still returns only the same 2 recent threads.

    This appears to be deeper than project grouping or the old limit >= 50 regression: even a 49-item request does not enumerate the existing active sessions, while direct lookup by exact ID works. The durable rollout files remain a valid source of truth, but the current app does not backfill/reconcile them into the live thread listing.

    Please add a supported, non-destructive reindex/recovery path that scans sessions/**/*.jsonl, validates each session independently, and reconstructs the list/sidebar metadata without requiring users to edit SQLite or remember thread titles/IDs.

  7. boombx403-byte commented on Aug 18, 2026

    @boombx403-byte
    boombx403-byte
    on Aug 18, 2026

    Hi @Atletico1999, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

    If you still have the affected local Codex directory, you can inspect it via:

    pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

    No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.

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

    CLIIssues related to the Codex CLIappIssues 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