Failed to archive conversation + seeing threads that do not have any reason for existing?

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

• #28080
• #27202
• #27513
• #28204

Powered by Codex Action

Issue is still happening after updating to 26.609.71450

Looks like 26.611.61753 is not displaying those random threads in the sidebar anymore.

Issue happens again on 26.616.71553 - random threads reappeared

I’m seeing this on Codex Desktop 26.616.81150 on macOS as well.

Local evidence from one affected thread:

• UI archive action shows Failed to archive conversation.
• The app-server log records a thread/archive RPC for the thread:

019ea801-c5a4-70f2-a825-20f3f52d210f

• After the RPC, the canonical row in ~/.codex/state_5.sqlite still has:

archived = 0
archived_at = null

• The rollout file still exists:

~/.codex/sessions/2026/06/09/rollout-2026-06-09T00-12-29-019ea801-c5a4-70f2-a825-20f3f52d210f.jsonl

• The app-level thread archive API cannot see the same thread ID and returns:

No Codex thread found for threadId: 019ea801-c5a4-70f2-a825-20f3f52d210f

• Searching for the thread from the app thread index also returns no rows, even though SQLite still has the thread.

This seems like the archive RPC is being invoked, but the archive state is not persisted, and then the app/index layer cannot resolve the still-existing thread. I’m also seeing this pattern across multiple recent thread/archive RPCs, not just this one thread.

I’m seeing what looks like the same issue on Codex Desktop 2026.06.28.063306-1 / codex-cli 0.142.3.

Symptoms:

• Sidebar gets polluted with many New chat entries.
• This seems to happen when subagents spawn or when new chats are created.
• Archiving those entries from the UI fails with Failed to archive conversation.
• Clicking/resuming one of them can fail with:

Failed to resume chat: no rollout found for thread id <id>.

Local evidence:

• ~/.codex/state_5.sqlite had many unarchived rows with source='subagent'.
• The app archive API failed on those leaked subagent IDs with No Codex thread found.
• Launcher logs also showed IAB_LIFECYCLE entries for client-new-thread:*.

Workaround:

• Manually archiving the leaked source='subagent' rows in SQLite cleaned the sidebar.
• Disabling features.in_app_browser = false appears to reduce or stop the recurrence, but I’m still testing after reload.

This looks like subagent, ephemeral, or browser-sidebar threads are being surfaced as normal conversations, but later cannot be archived or resumed because they do not have a normal rollout/thread backing record.

Had same happening. Can't perform basic stuff like archiving the chats. Wow.

Still happening on Version 26.623.61825 • Released Jun 29, 2026

Finally fixed for me in "ChatGPT Codex"! The name is lame but good job on the bugfix.

Not for me - I actually have a new bug I guess

<img width="1132" height="712" alt="Image" src="https://github.com/user-attachments/assets/36df5283-fbfc-4ced-afa7-10bbd575964c" />

🤷🏼

<img width="1132" height="712" alt="Image" src="https://github.com/user-attachments/assets/f7b38c71-3d8e-4015-9c49-58e111dbbf06" />

Finally fixed for me in "ChatGPT Codex"! The name is lame but good job on the bugfix.

Thought it was fixed but I guess not.... aargh.

<img width="293" height="60" alt="Image" src="https://github.com/user-attachments/assets/1384e596-c9b6-4195-afcf-1c7aa980b97e" />

Seeing this on Windows app (see 019f63bb-0dd1-79d1-b5ad-7f5adc61a2bb)

The archive failure and “threads with no agent-created events” look related through missing ownership/provenance, not just archive UI state.

I would expect each thread to carry an owner record: visible user-created task, internal helper/title run, subagent/fork, recovered orphan, or imported/local-only session. Archive should then operate on that owner state and fail with a typed reason if ownership is missing or inconsistent. A random thread with no creation event should be repairable as an orphaned/recovered session, not left in a state where archive cannot decide what it is allowed to mutate.

I maintain Better Agent (https://github.com/ofekron/better-agent), where hidden/background sessions are still modeled as durable owners for exactly this reason. If useful, a star helps other desktop-agent builders find it.

I am also seeing this underlying issue in ChatGPT/Codex desktop 26.715.72359 (build 5718) on macOS 26.5.2.

In my case, an ephemeral/helper thread is exposed in the desktop UI as a resumable local task. Opening it causes thread/read to succeed, followed by an automatic thread/resume that fails with:

Failed to resume chat
no rollout found for thread id [redacted]

The persisted parent task remains healthy and resumable. The exposed helper has no saved rollout and is identified as ephemeral, so retrying cannot succeed.

Expected behavior: ephemeral/helper threads should not be exposed as resumable local tasks. If shown, they should be read-only or route back to the persisted parent, and the app should not issue thread/resume for a thread with no rollout.

I have the exact thread IDs, timestamps, and desktop log sequence available for maintainers through a private support channel if needed.

019f8cae-9822-7ef1-bb7d-f54ded3be374

<img width="339" height="81" alt="Image" src="https://github.com/user-attachments/assets/a54e0ae4-f083-4fe0-8c22-fde8f99bdef6" />

Maybe it's time for OpenAI to stop using Codex to write Codex

You can ask codex to archive it as a workaround

You can ask codex to archive it as a workaround

<img width="458" height="172" alt="Image" src="https://github.com/user-attachments/assets/3a57beb8-fee3-4ea2-8379-fb75da9e11a8" />

Ask in a separate thread

Now no threads can be archived. All are erroring: Failed to archive conversation. Annoying.

The conversation was archived successfully.

Cause: its thread ID was valid, but the local database stored its file path with a malformed \\?\ prefix.
I backed up the database, corrected only this thread’s path, and archived it normally.

Backup: [state_5.sqlite.before-archive-01a007d3.bak](C:/Users/User/.codex/state_5.sqlite.before-archive-01a007d3.bak)

There are 28 other unarchived records with the same path format, so this error may recur.

Ask in a separate thread

• solution

repair script is as follows; simply enter the session_id list.
fix_codex_session_paths.py

• ps

archive chats before restarting codex; otherwise the chats unarchived will reproduce this problem

2026-08-21; bug is fixed in windows,