Codex Desktop Recents lists CLI-created threads that cannot be archived and are invisible to the chatgpt.com/codex web UI

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

26.818.41509

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Threads created headlessly via the Codex CLI (not through the Desktop app UI) mostly archive normally from Codex Desktop — but a small, persistent subset get stuck: Archive fails every time with "Failed to archive chat," and those same threads are invisible to the chatgpt.com/codex web UI, so there is no way to remove them from either surface.

This is not "CLI threads can't be archived" in general — I've successfully archived the great majority of my CLI-created threads through the same Desktop UI. Right now exactly 4 are stuck this way, all currently visible in my Recents sidebar:

• 01a02d86-6426-7932-acb0-d8b879da46ba — task A (a test-tooling task; title redacted, private project)
• 01a0201c-e330-7290-a096-4456ea861b54 — task B (a UI bug-fix task; title redacted, private project)
• 01a02019-f00c-7bd0-9226-375f6366b35a — task C, same underlying bug-fix as task B, re-run (title redacted, private project)
• 01a01db8-ec06-7690-a030-761ab6f9fb68 — task D (a feature-implementation task; title redacted, private project)

One data point that may help narrow the cause: for the first thread above, a second thread exists with the identical title (same task, re-run), id 01a02d86-15f5-7750-b7e7-8efe82ace0f7 — and that one archived successfully. So whatever distinguishes the stuck threads isn't the task content or title; something about these specific four (or their creation circumstances) differs from otherwise-identical siblings that archived fine.

Concretely:

• Clicking Archive on any of the four in Codex Desktop fails with "Failed to archive chat." Reproduced live today (2026-08-24) on the first one listed above.
• None of the four appear anywhere in chatgpt.com/codex/cloud: the Tasks and Archive tabs are empty, and the backend "Search tasks" box returns "No matching tasks" both for generic terms and for each thread's own title text.
• Local remediation attempts (see "What was ruled out" below) all fail because Recents is served from the backend, not from local state — so there's no client-side workaround either.

This looks like the Desktop app is listing threads that its own archive endpoint (and the web app's endpoints generally) don't recognize as belonging to it — for some threads but not others created the same way.

What steps can reproduce the bug?

I don't have a reliable way to make a specific thread land in the stuck state on demand — most threads created the same way archive fine, and I haven't isolated what differs about the ones that don't (see the sibling-thread data point above). What's reliably reproducible is the failure mode on the four already-stuck threads:

1. Open Codex Desktop (embedded in ChatGPT.app on macOS) with an account that has CLI-created threads in Recents.
2. Right-click a thread that's already stuck (e.g. id 01a0201c-e330-7290-a096-4456ea861b54, task B above) → Archive → toast: "Failed to archive chat." Reproduced live today, 2026-08-24.
3. Separately, open chatgpt.com/codex/cloud (logged into the same account) and check the Tasks and Archive tabs, and the "Search tasks" box, for that thread's title → nothing found on any of the three (checked 2026-08-23).

For what it's worth in case it's relevant to timing/onboarding rather than something inherent to these four threads: they range from 2026-08-20 to 2026-08-24 in age, and a fresh batch of same-shaped CLI-originated threads (parent 01a032be-894c-7a03-955d-e522a955387e plus three spawned children) was created via the same CLI path on 2026-08-24 without (yet) getting stuck — so age/staleness alone doesn't predict it either.

What is the expected behavior?

Either:

• The Archive action succeeds for these threads too, the same as it does for the great majority of CLI-originated threads, or
• Threads the web app's own endpoints don't recognize (per the Tasks/Archive/Search-tasks checks above) shouldn't be listed in Desktop Recents in the first place.

Additional information

What I ruled out locally before concluding this needs a backend-side fix (macOS, Codex Desktop embedded in ChatGPT.app):

• Editing ~/.codex/session_index.jsonl — that's a display-name cache only; the thread persists and gets retitled from its first message.
• Moving the rollout file out of ~/.codex/sessions, including into the Desktop app's own ~/.codex/archived_sessions/ — the Recents entry survives a full quit/relaunch of the app.
• Searching all local web storage (Local Storage, Session Storage) and disk for the thread UUID — it appears nowhere except the rollout file itself, which points to Recents being served remotely rather than reflecting local state.

I searched existing issues before filing and didn't find an exact match, but flagging the closest related ones in case they share root cause:

• #28276 — "Failed to archive conversation" for threads that "magically" appeared (attributed there to subagent-sourced threads leaking into the sidebar) — same archive failure, different reported origin.
• #39195 — Windows-specific: CLI threads leaked into Desktop Recents via a shared CODEX_HOME with a custom local model provider; there, Archive eventually started working after repeated app restarts, and no web-UI-invisibility angle was reported.
• #40219 — server-deleted conversations repopulating in Recents and not removable — different mechanism (deletion vs. CLI-origin), same "stuck in Recents with no removal path" symptom class.

None of the three describes the specific combination here (CLI-headless origin + archive failure + total invisibility to the web UI's Tasks/Archive/Search), so filing as a new report rather than a duplicate.