codex - 💡(How to fix) Fix Mac app hides older local conversations after update because bogus root-level `status` sessions flood recent local history [2 comments, 3 participants]

What version of the Codex App are you using (From “About Codex” dialog)?

26.415.30602 (1773)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

After updating and/or relaunching the Codex Mac app, all older local conversations disappeared from the sidebar. Only cloud conversations were visible, plus the new conversation I started to investigate this issue. This new conversation persisted across all restarts while investigating.

The local data was not deleted. The older conversations were still present on disk in ~/.codex/sessions, and they also existed in ~/.codex/state_5.sqlite.

What appears to be happening is:

• At some point the app created a large number of bogus local sessions with:
  • source='cli'
  • cwd='/'
  • first_user_message / title values like status, atus, tus, us, s, status/status, us/status
• In my case there were about 100 of these bogus root-level sessions.
• They were newer than my real local conversations, with timestamps from April 16-17, 2026.
• I had not been using the Codex CLI recently, so these do not seem to correspond to intentional CLI usage.
• The app appears to only load a recent subset of local conversations. I saw telemetry/log evidence of thread_count_loaded_recent=50, and because the bogus sessions occupied that recent window, the real local conversations were pushed out of view.
• The app also logged warnings like No cwd found for local task conversationId=... for those bogus thread IDs.

Things that did not fix it:

• Restarting the app
• Clearing app-side cache/storage
• Rebuilding or deleting state_5.sqlite
• Rebuilding or deleting session_index.jsonl (when present)
• Archiving the bogus rows in state_5.sqlite only

DB-only fixes were not durable because on relaunch the app re-imported the bogus sessions from ~/.codex/sessions.

Workaround that worked

1. Back up ~/.codex/state_5.sqlite.
2. Identify the bogus rollout JSONL files under ~/.codex/sessions/... that correspond to the root-level status / atus / tus / us / s sessions.
3. Move those bogus rollout files out of ~/.codex/sessions to a backup/quarantine folder.
4. Mark the matching rows in ~/.codex/state_5.sqlite as archived.
5. Relaunch the app.

After removing those bogus rollout files and re-archiving the matching DB rows, the older local conversations reappeared.

What steps can reproduce the bug?

1. Start with an existing Codex Mac app setup that already has many local conversations stored in ~/.codex/sessions.
2. Update the Codex Mac app.
3. Quit and relaunch the app.
4. Open the sidebar and compare local history.
5. Observe that older local conversations are missing, while cloud conversations and the current/new local conversation still appear.
6. Inspect ~/.codex/state_5.sqlite after relaunch.
7. Observe many newly created local rows with source='cli', cwd='/', and titles / first messages like status, atus, tus, us, s.

Manual reproduction attempt If the above doesn't repro, the symptom can likely be reproduced by seeding bogus local session rollouts and relaunching Codex:

1. Start with a Codex Mac app profile that already has real local conversations in ~/.codex/sessions.
2. Add at least 50 newer bogus rollout files under ~/.codex/sessions/... that look like local CLI/TUI sessions with:
   • source="cli"
   • originator="codex-tui"
   • cwd="/"
   • user message / title values like status, atus, tus, us, or s
3. Remove or rebuild ~/.codex/state_5.sqlite so the app re-imports session history from ~/.codex/sessions.
4. Relaunch Codex.
5. Observe that older real local conversations disappear from the sidebar, while newer cloud/current conversations still appear.

What is the expected behavior?

Existing local conversations should still appear in the sidebar after updating and relaunching the Mac app. The app should not generate bogus root-level status sessions that displace real local conversation history.

Additional information

No response