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

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

• #17540
• #17304
• #17317
• #17970
• #16549

Powered by Codex Action

+1

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

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

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

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

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.

Update after further local investigation: my current recurrence looks like the same general sidebar/index failure class, but in my case the flood is mostly Symphony-generated Codex threads rather than status sessions.

Additional local evidence:

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

find ~/.codex/sessions -type f -name '*.jsonl' | wc -l
# 206

wc -l ~/.codex/session_index.jsonl
# 38 ~/.codex/session_index.jsonl

What I found:

• The real data still appears present locally: state_5.sqlite has ~209 thread rows and ~/.codex/sessions has ~206 rollout files.
• The sidebar-oriented lightweight index only has 38 entries, which is much closer to the expected human-visible session count.
• Most of the 209 DB rows are unattended Symphony worker/retry threads. Many have titles that are the entire Linear issue prompt, not a normal human thread title.
• The visible sidebar started showing project sections as No chats around Apr 28, 2026 11:39 PM HST.
• Around the same time, multiple codex ... app-server processes were running and holding ~/.codex/state_5.sqlite open.
• This does not currently look like deletion: only 2 DB threads are archived, and the rollout files remain on disk.

Closest related issue I found is #17304. The overlap is that temporary/derived/non-human sessions can dominate or confuse Desktop project sidebar grouping even while real local session data still exists. My variant seems to be: Symphony-created Codex threads are persisted into the same thread store as human sessions, and then the project sidebar/index or workspace-root hints get rebuilt incorrectly under that load/concurrency.

So I would refine the hypothesis here from “sessions are gone” to: Desktop is mixing automation-generated threads with human-visible conversations in a way that can corrupt or starve the project sidebar grouping/index.

Will this be fixed anytime soon? have multiple dozen of chats no longer showing in the codex desktop app after this update every though they actually exist...

same issue here

I can confirm the same failure mode on another macOS machine, and the local evidence points to CodexBar as a likely trigger.

Local shape of the bogus sessions:

source = 'cli'
cwd = '/'
title = first_user_message
title in ('status', 'atus', 'tus', 'us', 's', 'tatus', 'status/status')

The matching rollout JSONL files looked like CLI sessions started only for a status-like prompt: source="cli", cwd="/", and a first user message such as status, atus, tus, us, or s. They then occupied the Desktop sidebar's recent/local history window and hid older real conversations even though the real threads were still present in state_5.sqlite.

In this case, the safest workaround was not to edit SQLite directly. This worked:

1. Quit/uninstall CodexBar, or disable its Codex status/usage polling if possible.
2. In Codex Desktop, open the sidebar organization view.
3. Switch to chronological ordering.
4. Use "Load more" until the bogus status / atus / tus / us / s sessions appear.
5. Manually archive those bogus sessions through the Codex Desktop UI.

After manually archiving the bogus sessions, the previously missing older conversations immediately reappeared in the sidebar.

This UI-based archive path seems safer for users than directly editing ~/.codex/state_5.sqlite, because it uses Codex Desktop's own archive operation and avoids touching rollout files. If the bogus sessions are re-imported after restart, then the stronger workaround mentioned above in this issue may still be needed: quarantine the matching bogus rollout .jsonl files from ~/.codex/sessions and archive the exact matching DB rows.

I also opened a matching CodexBar issue here: https://github.com/steipete/CodexBar/issues/953

Adding another data point from Codex Desktop on macOS, observed on 2026-06-23.

Symptoms:

• UI micro-freezes / beachballs every few seconds.
• Codex main + renderer processes spike during the freezes; I sampled the main process around ~100% CPU during bursts.
• Desktop logs flood with repeated lines like No cwd found for local task conversationId=..., growing by MBs over short windows.
• Blocking diagnostic inserts into ~/.codex/logs_2.sqlite did stop the diagnostic log DB from growing, but did not fix the UI freezing. So this appears to be a separate local-thread/history issue.

Local state evidence from ~/.codex/state_5.sqlite:

• There were ~1,690 active rows matching archived=0 AND source='cli' AND cwd='/' AND has_user_event=0.
• Many of those rows had blank titles/previews or fragments of status: status, atus, tus, us, s.
• On app restart, a subset of those same rows became active again after being archived, which suggests startup/backfill/thread-list logic may be reviving malformed session records from old JSONL files.
• There were also hundreds of active rows pointing at non-existent local cwd paths; those produced the same No cwd found warning pattern.

Local mitigation that stopped the freeze/log loop:

• Backed up the DB.
• Archived the missing-cwd rows.
• Archived the source='cli' AND cwd='/' AND has_user_event=0 rows.
• Added a narrow local SQLite guard only for the known bad IDs so they could not be reactivated.
• Active visible thread rows dropped from ~2,146 to ~151.
• The No cwd found spam stopped, log growth dropped from MB bursts to tiny normal increments, and CPU settled.

I would not recommend this SQLite trigger/guard as a real user-facing fix, but it points to possible upstream fixes:

• Quarantine/ignore malformed root-cwd, no-user-event status fragment sessions during import/backfill.
• Ensure archived local thread rows are not resurrected from old session JSONL on launch.
• Make thread/list skip or repair local tasks with no resolvable cwd instead of repeatedly logging them.
• Deduplicate/rate-limit the No cwd found warning so one bad history cluster cannot freeze the UI.
• Consider a supported repair local history command for this class of local-state corruption.

Happy to provide more sanitized query output if useful.