You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Desktop app: delegated/worktree tasks fail to archive with "no rollout found" #33120
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.72221
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
Archiving delegated/worktree tasks from the Codex desktop app fails. The archive request returns:
no rollout found for thread id <thread-id>
The app then logs:
Inactive thread archive did not persist
For a materialized completed task, the app reports that the session is archived when resuming it while archive persistence still fails, leaving a contradictory archived/not-persisted state. An unmaterialized delegated placeholder fails with the same missing-rollout error.
What steps can reproduce the bug?
From a parent Codex task, create delegated tasks in isolated worktrees.
Let one delegated task remain an unmaterialized placeholder and let another complete.
Open either delegated task from the Codex desktop sidebar.
Choose Archive.
Observe the error and the task remaining visible or entering an inconsistent state.
Affected task IDs:
019f6180-32d9-73e2-9601-ac1fbe0c77db — unmaterialized delegated placeholder; thread/read says it is not materialized and has no first user message.
019f6180-2142-7870-894c-51bb107c4150 — completed materialized delegated task; resume says it is archived while archive persistence fails.
Related /feedback reference: 019f61c6-900a-7833-ad66-36639ab9981f.
What is the expected behavior?
Archive should succeed cleanly for both materialized delegated tasks and unmaterialized delegated placeholders. The task should be removed from the active list without entering a contradictory archived/not-persisted state.
Additional information
The local desktop log recorded the failures on 2026-07-14 between 17:51:36Z and 17:51:59Z as method=thread/archive, code=-32600, with the missing-rollout message followed by Inactive thread archive did not persist.
The bug was also recorded through Codex /feedback without uploading full logs.
Additional reproduction: this is not limited to delegated/worktree tasks.
On Windows, Codex Desktop 26.818.22352, archiving a completed ordinary local Codex task failed with the UI toast “Chat archiving failed”. The task was a normal local project task (not a delegated task and not a worktree placeholder).
Sanitized local evidence:
The task had completed successfully and thread/read reported no active turn.
The task's rollout/session JSONL existed locally.
Desktop dispatched thread/archive; the app-server log recorded had_active_turn=false, then shut down the task loop and cleared its listener.
Afterward, the local threads row still had archived=0 and archived_at=NULL; the task remained in the active list and did not appear in Archived tasks.
There was no archive error or "no rollout found" message for this target in the local log.
This suggests the archive request can reach the local backend and tear down an idle normal task, yet fail between that teardown and persistence of archive state. Please broaden investigation beyond delegated/worktree task materialization, and make the UI return the underlying persistence failure rather than a generic toast.
I can provide the thread ID and a narrowly redacted log excerpt privately if maintainers need them.
Activity
Lesterffx commentedon Aug 21, 2026
Additional reproduction: this is not limited to delegated/worktree tasks.
On Windows, Codex Desktop
26.818.22352, archiving a completed ordinary local Codex task failed with the UI toast “Chat archiving failed”. The task was a normal local project task (not a delegated task and not a worktree placeholder).Sanitized local evidence:
thread/readreported no active turn.thread/archive; the app-server log recordedhad_active_turn=false, then shut down the task loop and cleared its listener.threadsrow still hadarchived=0andarchived_at=NULL; the task remained in the active list and did not appear in Archived tasks.This suggests the archive request can reach the local backend and tear down an idle normal task, yet fail between that teardown and persistence of archive state. Please broaden investigation beyond delegated/worktree task materialization, and make the UI return the underlying persistence failure rather than a generic toast.
I can provide the thread ID and a narrowly redacted log excerpt privately if maintainers need them.