Codex Desktop: archived local thread disappears from both active and Archived lists; unarchive fails with missing hostId

Open 💬 2 comments Opened Jun 9, 2026 by Audacity88
💡 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.602.71036

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 23.6.0 arm64 arm

What issue are you seeing?

Archiving a local Codex Desktop thread can hide it from both the normal thread list and the Archived list. The thread record and transcript still exist, and the thread can still be read by exact thread id, but the UI no longer surfaces it.

I also saw a related unarchive UI state problem: when unarchiving another archived chat, the unarchive actually succeeded, but the Archived page stayed stuck with a toast reading Unarchiving chat... and disabled Unarchive buttons. So the backend state and the Archived UI can drift in both directions.

Observed failure mode:

  • user clicks Archive on a local desktop thread;
  • the thread disappears from the active/sidebar list;
  • the same thread does not appear in Archived search/list;
  • direct lookup by exact thread id still works;
  • attempting to unarchive through the app thread API fails with:
set_thread_archived requires hostId for unloaded thread <thread_id>

Concrete local evidence from one affected thread:

thread id: 019ea801-c5a4-70f2-a825-20f3f52d210f
title: Quill (docs)
read_thread by id: succeeds
list_threads(query="Quill"): returned no threads while archived
threads.archived in ~/.codex/state_5.sqlite: 1
threads.rollout_path: ~/.codex/archived_sessions/rollout-2026-06-09T00-12-29-019ea801-c5a4-70f2-a825-20f3f52d210f.jsonl
unarchive attempt: requires hostId for unloaded thread 019ea801-c5a4-70f2-a825-20f3f52d210f

Manual recovery required backing up local state, copying the rollout JSONL back under ~/.codex/sessions/2026/06/09/..., and updating only that thread row to archived = 0, archived_at = NULL, the active rollout_path, and thread_source = 'user'. After that, list_threads(query="Quill") found the thread again.

This looks like a Codex Desktop indexing/host metadata bug: Archive can produce an archived, unloaded local thread that has enough persisted state to be read by id, but lacks the host/index metadata needed to appear in Archived or be unarchived normally.

What steps can reproduce the bug?

I do not yet have a minimal clean-profile repro, but this happened repeatedly on a real macOS profile with pinned local threads.

Observed sequence:

  1. In Codex Desktop, open a local saved workspace with a pinned local thread.
  2. Use the UI Archive button on that thread.
  3. Search for the thread title in the active/current list.
  4. Search for the same title in Archived.
  5. Attempt to unarchive the thread by id through the app thread API.

Actual result:

  • active/current search returns nothing;
  • Archived search returns nothing;
  • direct read by exact thread id succeeds;
  • unarchive by id fails with requires hostId for unloaded thread;
  • SQLite shows threads.archived = 1 and a rollout path under ~/.codex/archived_sessions.

Related observed UI state:

  1. Open Archived chats.
  2. Click Unarchive on an archived chat that is visible in the Archived list.
  3. The unarchive succeeds, but the page remains stuck showing Unarchiving chat... and the row buttons remain disabled.

What is the expected behavior?

Archiving should make the thread visible in the Archived list, and Unarchive should work for any archived local thread that still has readable local state.

More specifically:

  • Archived local threads should remain discoverable in Archived search/list.
  • The app should not require unavailable hostId metadata to unarchive a local unloaded thread.
  • If a thread can be loaded/read by exact id, the app should be able to materialize enough metadata to show it in Archived and unarchive it.
  • The active/current list and Archived list should not both omit the same existing thread.
  • After a successful unarchive, the Archived page should clear the pending toast/button state and refresh the list.

Additional information

Related issues I found before filing: #20317, #25769, #23979, #22592, #20608, and #11907. This may be in the same bug cluster, but I did not find an exact match for the requires hostId for unloaded thread failure.

No raw rollout files, logs, auth files, or full state databases are attached because they can contain private prompts, local project names, and account metadata. I can provide redacted SQL output or specific metadata fields if maintainers say what is useful.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26634
  • #27159
  • #26647
  • #26174

Powered by Codex Action

the1337moderator · 1 month ago

Additional Windows reproduction of the same archive/index/state-divergence bug, with a different unarchive failure.

Environment

  • Codex Desktop: 26.707.9981.0
  • Windows 11 Pro, version 10.0.26200, 64-bit

Observed behavior

  1. An archived local task could not be restored through the Codex Desktop UI.
  2. Agent-facing thread search could locate the task by title, and direct read_thread by its known ID succeeded. Its initial runtime state was notLoaded.
  3. Repeated calls equivalent to set_thread_archived({ archived: false, threadId }) failed with:

``text
No Codex thread found for threadId: <redacted>
``

  1. Direct navigation to the known thread ID returned success and changed the runtime state from notLoaded to idle, but another unarchive call still returned the same error.
  2. Sending a follow-up to the known thread ID succeeded, and the task became active/resumable. This restored execution capability but did not restore normal sidebar/list visibility.
  3. The task still did not appear normally in the Codex UI. It became visible only after pinning it and relaunching Codex in a new window.

This appears to be a partial resurrection: the task can be searched/read/navigated/continued by ID, while the archive flag, thread registry, and sidebar index disagree. Pinning plus a new window seems to force a separate visibility/index path; it is not a reliable unarchive operation.

Expected behavior

  • If an archived thread is readable and addressable by ID, Unarchive should succeed.
  • Unarchive should atomically reconcile the persisted archive state, runtime/thread registry, and sidebar index.
  • The restored task should immediately appear in the normal task list without requiring pinning or a new Codex window.
  • A task should not be executable while remaining effectively archived or omitted from the ordinary UI.

Privacy

No transcript, prompts, task title, thread ID, project/workspace name, rollout file, database, logs, or source code are attached. I can provide narrowly scoped, redacted metadata if maintainers request specific fields.