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

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

26.609.41114

What subscription do you have?

Pro 20x

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Trying to archive a chat fails with "Failed to archive conversation".

This seems to happen in threads that "magically" appeared. By "magically" I mean that I did not spawn them via CLI or Codex App, and that the original thread where they would be spawned in (as they are part of a given worktree + git branch) does NOT signal any agent created events. Furhtermore, AFAIK, subagent threads do not show in the main UI anyway.

Feedback IDs:
019ec7c8-ecba-7a73-9d0d-4d17abb29905
019ec7e5-544d-7560-974d-0e25902cae81 (random thread)

What steps can reproduce the bug?

I am not sure at this time.

What is the expected behavior?

Thread archiving should work correctly.

(Potentially - unconfirmed) Subagent threads should not show up in the Codex App.

Additional information

Feedback IDs:

019ec7c8-ecba-7a73-9d0d-4d17abb29905
019ec7e5-544d-7560-974d-0e25902cae81 (random thread)

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

Desktop thread tools intermittently lose handlers (No handler registered) within an active session #28080
Codex Desktop: archived local thread disappears from both active and Archived lists; unarchive fails with missing hostId #27202
Ambiguous thread tooling causes subthread requests to create visible Codex threads instead of subagents #27513
Codex App create_thread worktree rows fail with 'Worktree init failed' and no recoverable error #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

🤷🏼

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.

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

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

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

Ask in a separate thread

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,

Same here. Still got the same issue on version 26.903.61454

Same here. Still got the same issue on version 26.903.61454

Did you switch accounts?

I can confirm this is still happening in Codex Desktop 26.928.21956 on macOS with remote SSH chats. The sidebar shows multiple old rows titled only by their working-directory paths. Opening one fails with no rollout found for thread id; trying to archive it also fails. The affected ID is absent from the readable thread list and the remote thread database. Refreshing sidebar grouping/sort removed some rows, but others remained after fully restarting the app. Active chats remain accessible. This resembles the ghost-conversation behavior in #29868, which was closed as completed. Could the sidebar safely discard orphaned entries when no rollout exists?

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jun 15, 2026

ebarti commented on Jun 16, 2026

ebarti commented on Jun 17, 2026

ebarti commented on Jun 23, 2026

Audacity88 commented on Jun 24, 2026

OmerFarukOruc commented on Jun 28, 2026

MoralStrike commented on Jun 29, 2026

ebarti commented on Jun 29, 2026

Audacity88 commented on Jul 9, 2026

ebarti commented on Jul 9, 2026

Audacity88 commented on Jul 12, 2026

kendonB commented on Jul 18, 2026

SamZhang0 commented on Jul 23, 2026

kendonB commented on Jul 25, 2026

FreedomLabsIO commented on Aug 18, 2026

kendonB commented on Aug 18, 2026

FreedomLabsIO commented on Aug 18, 2026

kendonB commented on Aug 18, 2026

FreedomLabsIO commented on Aug 19, 2026

cry11111 commented on Aug 20, 2026

cry11111 commented on Aug 21, 2026

lacsonmarkkevin commented on Sep 10, 2026

cry11111 commented on Sep 10, 2026

Lchangliang commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions