Desktop project sidebar shows No chats after Symphony automation creates many threads

[jskoiz]

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

26.422.71525 (build 2210)

What subscription do you have?

Pro

What platform is your computer?

macOS 25.4.0, M3 Max

What issue are you seeing?

Codex Desktop is showing No chats for project sidebar sections even though the local session data still exists.

This happened twice on Apr 28, 2026 HST:

• 6:49 PM: project sessions were visible. One project was expanded and showed multiple sessions.
• 7:01-7:03 PM: most project sections changed to No chats while Codex was still open.
• 11:39 PM: the same No chats state showed up again.

This was not caused by deleting ~/.codex. Local state was still present.

During the first occurrence:

~/.codex/sessions had 137 rollout files
~/.codex/state_5.sqlite had 138 thread records
project threads still existed for multiple projects

I rebuilt ~/.codex/.codex-global-state.json workspace hints from the DB:

backup: /Users/jk/Desktop/codex-global-state-repair-20260428-190419
repaired hints: 131 thread-to-workspace mappings
JSON validated cleanly

After a full Codex restart, the sidebar still did not recover.

By the later recurrence:

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

Most of the extra thread rows were unattended Symphony worker/retry threads. Many had titles matching full Linear issue prompts rather than normal conversation titles. The 38 rows in session_index.jsonl looked much closer to the expected number of human-visible sessions than the 209 rows in threads.

This seems related to #17304 and #18364, but the trigger looks different: automation-created Symphony/Codex threads are being mixed into the same local thread store as normal Desktop conversations, and project sidebar grouping starts failing once that thread volume builds up.

What steps can reproduce the bug?

I do not have a minimal repro, but this is the pattern that reproduced it for me:

1. Use Codex Desktop across multiple projects with normal visible project sessions.
2. Run Symphony/unattended issue workers that create many Codex threads or retries across per-issue workspaces.
3. Keep using or restart Codex Desktop after those automation-created threads accumulate.
4. Project sections can start showing No chats, even though the underlying SQLite rows and rollout files still exist.

What is the expected behavior?

Automation-generated threads should not hide or break grouping for human-visible Desktop conversations.

Desktop should separate or filter automation/internal threads from the normal project sidebar index, or provide a repair/reindex path when local state gets into this condition.Automation-generated threads should not hide or break grouping for human-visible Desktop conversations.

Desktop should separate or filter automation/internal threads from the normal project sidebar index, or provide a repair/reindex path when local state gets into this condition.

Additional information

No response

[github-actions]

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

• Desktop project sidebar hides sessions when Symphony automation threads flood local thread store #20185
• threads / projects in sidebar missing  #18640
• Windows Desktop: sidebar/project list lost after update; search still finds threads; projectless-thread-ids workaround restores flat chats but project grouping remains broken #19873

Powered by Codex Action

[jojopirker]

I had a similar issue with the sidebar (#18640). I asked codex to fix it, but thats not a reliable solution. Still maybe it can also help you: #18640 (comment)