Mac app hides older local conversations after update because bogus root-level `status` sessions flood recent local history

[ashughes]

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

[github-actions]

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

• Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540
• Desktop project sidebar hides active threads after state DB migration drift and stale temporary sessions #17304
• Multiple sidebar bugs after workspace directory migration: "56 years ago" timestamps, missing threads, threads vanish on click (macOS) #17317
• Threads keep disappearing from the sidebar even with "All chats" selected #17970
• Codex threads disappear after a few days on macOS #16549

Powered by Codex Action

[human-bee]

+1

[jif-oai]

Hi,
Could you share with me a few of those bogus sessions file please?
You can send them on jif@openai.com to make things easier

In the meantime we will make sure the rest get fixed

[ashughes]

@jif-oai I just sent the bogus session files via email.

As I mentioned in my email, I noticed this issue happened again today when I tried to prepare the session files for you.

For this recurrence I found 359 bogus local session files under ~/.codex/sessions. They consistently looked like:

• source="cli"
• originator="codex-tui"
• cwd="/"
• user message usually "status", with truncated variants "atus", "tus", "us", "s", plus a few multiline status variants

Recovery this time was just:

1. Move the bogus session files out of ~/.codex/sessions
2. Restart Codex

That restored the missing local chats. I did not need to modify the SQLite database like I did last time.

[ashughes]

Possible lead: CodexBar may be generating these bogus local status sessions.

I can’t prove that yet, but this is why I suspect it:

• I have not manually used Codex CLI recently, so the bogus sessions marked source="cli" / originator="codex-tui" are unlikely to be from me directly running codex.
• The bogus local rollouts under ~/.codex/sessions had cwd="/" and first-user-message values like status, atus, tus, us, s.
• On my machine, CodexBar was configured with launchAtLogin=1, refreshFrequency=fiveMinutes, and selectedMenuProvider=codex.
• The bogus sessions were appearing at roughly a 5-6 minute cadence.
• CodexBar’s public docs/source say its Codex provider can use local Codex CLI RPC with PTY fallback, and that fallback can run codex and send /status:
  • https://github.com/steipete/CodexBar
  • https://github.com/steipete/CodexBar/blob/main/docs/codex.md

So CodexBar seems like a plausible way these local CLI-style status sessions could be created in the background.

That said, I do not think this fully explains the user-visible failure by itself, because moving the bogus session files out of ~/.codex/sessions and restarting Codex was enough to restore my missing local chats. So even if CodexBar is the trigger, Codex desktop still seems involved in how those bogus sessions are imported/rendered and end up hiding real local chats.

Version note: on April 20, 2026 I updated CodexBar twice (0.21 and then 0.22). I don’t know which version originally created the bad sessions, but it was likely older than 0.21.

I'll post an update here if it happens again (while CodexBar is version 0.22 or later).

[yvokeller]

+1, exact same issue. My real threads were still present in ~/.codex/state_5.sqlite, but the Desktop sidebar was effectively replaced by bogus local sessions with titles like status, atus, tus, us, and s, often with cwd='/' and empty git metadata. The app kept re-importing them from ~/.codex/sessions, so simple DB cleanup did not hold across restarts.

What finally fixed it for me was the workaround described here: quit Codex Desktop, quarantine the matching bogus rollout .jsonl files from ~/.codex/sessions, archive the exact matching bogus rows in state_5.sqlite, then relaunch. After that, my real projects and threads came back.

I also use the CodexBar, in case that helps narrow down the trigger or code path.

[jskoiz]

I hit a very similar issue on macOS, with one extra detail: it happened live while Codex was open, not only after restart/update.

Environment:

• Codex App: 26.422.71525 (build 2210)
• Platform: macOS
• Bundle ID: com.openai.codex

What happened:

• Most project folders in the sidebar suddenly changed to No chats.
• One project still showed a small subset of chats.
• Pinned chats still appeared.

Local data was still present:

sqlite3 ~/.codex/state_5.sqlite "select count(*) from threads;"
# 140

sqlite3 ~/.codex/state_5.sqlite \
  "select count(*) from threads where archived=0 and agent_role is null;"
# 133

I also had Chronicle enabled, so I have screen-history evidence:

• Around 7:00 PM HST, project chats were visible in the sidebar.
• Around 7:01 PM HST, the sidebar showed No chats for most projects while Codex was still open.
• I did not delete ~/.codex.

I tried restarting Codex, checkpointing SQLite WAL files, and rebuilding thread-workspace-root-hints in ~/.codex/.codex-global-state.json; the sidebar did not recover.

This looks like the Desktop sidebar/index losing project chat associations even though the local thread/session data remains intact.