[macOS Desktop] Symphony-created archived agent threads persist as hundreds of phantom sidebar chats

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

26.831.21537

What subscription do you have?

Plus

What platform is your computer?

Darwin 27.0.0 arm64 arm

What issue are you seeing?

NB: All of this report is generated by ChatGPT—I do not understand any of what it did, but it fixed the problem.

After using OpenAI Symphony to work on a Linear ticket, ChatGPT/Codex Desktop displayed hundreds of Symphony-created agent threads as ordinary chats in the Desktop sidebar.

A single Symphony workspace produced 525+ visible conversations associated with:

/Users//.<repo_name>/workspaces/<workspace_name>

These chats persisted after the Symphony run had finished and also persisted when switching ChatGPT accounts, indicating that they were local rather than account-scoped.

The affected sessions had already been archived under:

~/.codex/archived_sessions/

but ChatGPT/Codex Desktop continued to surface them as normal chats.

I eventually traced the persistent sidebar entries to:

~/.codex/sqlite/codex-dev.db

specifically the local_thread_catalog table.

Deleting only the affected local_thread_catalog rows caused the phantom chats to disappear.

This appears to be a synchronisation/garbage-collection issue between Symphony/app-server sessions and the Codex Desktop local thread catalogue.

There was no application error message.

What steps can reproduce the bug?

Run OpenAI Symphony against a Linear ticket so that it creates multiple Codex agent/app-server sessions in a workspace.
Open ChatGPT/Codex Desktop.
Observe that Symphony-created agent sessions appear as individual normal chats in the Desktop sidebar.

In my case, the affected workspace was:

/Users//.<repo_name>/workspaces/<workspace_name>

The number of entries actually increased while Desktop was running. For example:

cwd threads

---

/Users//.<repo_name>/workspaces/<workspace_name> 358

Running the query again shortly afterwards returned 364, and it eventually reached 525.

The query used was:

sqlite3 -header -column ~/.codex/state_5.sqlite '
SELECT
cwd,
COUNT(*) AS threads
FROM threads
WHERE cwd LIKE "%/workspaces/%"
GROUP BY cwd
ORDER BY threads DESC;
'

lsof ~/.codex/state_5.sqlite showed that the process writing this database was the Codex app-server bundled with ChatGPT Desktop:

/Applications/ChatGPT.app/Contents/Resources/codex ... app-server ...

After completely quitting Desktop, the count stopped increasing:

525

wait 10 seconds

525

I then identified all affected thread IDs. There were exactly 525, and they mapped 1:1 to 525 rollout-*.jsonl files under:

~/.codex/archived_sessions/

I quarantined those 525 rollout files and deleted the corresponding records from ~/.codex/state_5.sqlite.

Afterward:

SELECT COUNT(*)
FROM threads
WHERE cwd='/Users//.<repo_name>/workspaces/<workspace_name>';

returned:

0

There were also no matching entries in session_index.jsonl.

However, after reopening Desktop, all of the chats were still visible.

Searching the remaining local state showed that the thread IDs were also present in:

~/.codex/sqlite/codex-dev.db

which contains:

CREATE TABLE local_thread_catalog (
host_id TEXT NOT NULL,
thread_id TEXT NOT NULL,
display_title TEXT NOT NULL,
source_created_at REAL NOT NULL,
source_updated_at REAL NOT NULL,
cwd TEXT,
source_kind TEXT NOT NULL,
...
PRIMARY KEY (host_id, thread_id)
);

Finally, with Desktop quit, I ran:

DELETE FROM local_thread_catalog
WHERE cwd='/Users//.<repo_name>/workspaces/<workspace_name>';

After reopening Desktop, all of the phantom chats were gone.

Session ID/token/context-window usage does not appear applicable: this occurred across hundreds of Symphony-created agent sessions rather than one particular model invocation.

What is the expected behavior?

Symphony/internal agent sessions should either not appear as independent ordinary conversations in the ChatGPT/Codex Desktop sidebar, or they should be removed from the visible local catalogue when those sessions are archived or otherwise cease to exist.

In particular, once a thread no longer exists in the canonical thread/session store, local_thread_catalog should reconcile that state rather than retaining an independently visible sidebar entry indefinitely.

Switching ChatGPT accounts should also not expose the same stale locally generated agent conversations as though they were normal user chats.

Additional information

Platform: macOS, Apple Silicon.

Symphony was being used to process a Linear ticket. The default shared CODEX_HOME (~/.codex) was being used.

The relevant local state appeared to be:

Symphony/app-server sessions
↓
~/.codex/archived_sessions/
↓
~/.codex/state_5.sqlite
↓
~/.codex/sqlite/codex-dev.db
└── local_thread_catalog
↓
Desktop sidebar

The important observation is that removing the backing rollout files and corresponding state_5.sqlite thread records was not sufficient. The sidebar entries persisted until their rows were removed from local_thread_catalog.

This suggests that local_thread_catalog can retain visible threads after their backing sessions have been archived or removed, without a subsequent reconciliation/garbage-collection step.

In this case, one Symphony workspace resulted in 525 stale/phantom Desktop conversations.

I have retained backups of the affected local databases/state if further diagnostics would be useful.

Start with the macOS Desktop app-server flow that populates local_thread_catalog in ~/.codex/sqlite/codex-dev.db, then compare it with archived_sessions and threads in ~/.codex/state_5.sqlite. Reproduce the Symphony workspace case and observe how archived or removed sessions are catalogued. Done means stale agent threads no longer remain visible in the sidebar after archival, removal, or account switching.