›_ Codex Issues
Codex Issues / #28276

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

Open 💬 13 comments Opened Jun 15, 2026 by ebarti
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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)

View original on GitHub ↗

13 Comments

github-actions[bot] contributor · 1 month ago

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

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

Powered by Codex Action

ebarti · 1 month ago

Issue is still happening after updating to 26.609.71450

ebarti · 1 month ago

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

ebarti · 27 days ago

Issue happens again on 26.616.71553 - random threads reappeared

Audacity88 · 26 days ago

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.

OmerFarukOruc · 22 days ago

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.

MoralStrike · 22 days ago

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

ebarti · 21 days ago

Still happening on Version 26.623.61825 • Released Jun 29, 2026

Audacity88 · 11 days ago

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

ebarti · 11 days ago

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" />

Audacity88 · 9 days ago
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" />

kendonB · 2 days ago

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

ofekron · 46 minutes ago

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.