Repository navigation
Codex Desktop archives and aborts a regular task while it is monitoring an open PR #32257
Description
What version of the Codex App are you using?
Codex Desktop client 26.707.31428; session metadata reports codex-cli 0.144.0-alpha.4.
What subscription do you have?
ChatGPT subscription; exact tier is not exposed in the diagnostic evidence collected for this report.
What platform is your computer?
Darwin 25.5.0 arm64 arm
macOS 26.5.1 (25F80)
What issue are you seeing?
Codex Desktop issued thread/archive for a normal user task while that task had an active turn and was waiting/polling for pull-request review and CI follow-through. The archive path submitted Shutdown and aborted the running task.
This was not only a sidebar/display problem: the active agent turn was terminated. The pull request was still open at the time. The task was later unarchived and resumed after user intervention.
The archive occurred in a short cleanup-like sequence alongside several completed tasks, suggesting an archive/cleanup selection race that incorrectly included a still-running task.
Sanitized log sequence from ~/.codex/logs_2.sqlite:
2026-07-10 15:38:46.900 EDT
Submission ... op: Shutdown
2026-07-10 15:38:46.900 EDT
aborting running task task_kind=Regular sub_id=<redacted>
2026-07-10 15:38:46.940 EDT
Shutting down Codex instance
2026-07-10 15:38:46.942 EDT
thread/archive ... client_name="Codex Desktop" client_version="26.707.31428" ... had_active_turn=true
The session ID is available privately if maintainers need it. It is redacted here because the issue tracker is public.
Additional checks:
- No
set_thread_archivedtool call appeared in the affected session. - The affected task was a regular user thread, not an automation run.
- The configured automations contained no instruction to archive this task.
- Live GitHub state confirmed the associated PR was still open when the task was aborted.
- Current state later showed the task unarchived, but the interrupted turn had already been lost.
What steps can reproduce the bug?
The exact cleanup trigger is not yet reliably reproducible, but the observed sequence was:
- Start a normal Codex Desktop task that creates or works on a pull request.
- Keep the task active in a PR follow-through loop, polling CI/review state with a long-running wait tool call.
- Desktop performs an archive/cleanup sequence for nearby completed tasks.
- The still-running task receives
thread/archiveeven though the server recordshad_active_turn=true. - The archive request submits
Shutdown, aborts the regular task, and removes it from the active task list while its PR remains open.
The key invariant violation is directly captured in the log: thread/archive was accepted with had_active_turn=true, immediately after aborting running task task_kind=Regular.
What is the expected behavior?
- Automatic or bulk cleanup must never archive a thread with an active turn.
thread/archiveshould reject or require explicit confirmation whenhad_active_turn=true; it should not silently abort a running task.- A task performing PR follow-through should remain active while its associated PR is open unless the user explicitly stops or archives it.
- If an archive is attempted against a running task, the UI should explain the conflict without terminating the turn.
Additional information
Related but distinct reports:
- Codex Desktop automation run is immediately auto-archived after start #19742 covers automation runs that are immediately auto-archived. This report is a regular user task, not an automation.
- Codex Desktop Windows: archiving the active thread succeeds, then UI repeatedly resumes archived thread and freezes #25713 and Codex Desktop macOS: archiving the currently viewed chat leaves right pane on archived thread and triggers
session is archived#25769 cover user-initiated archiving of the currently viewed thread followed by stale resume behavior. This report concerns an archive request arriving during an active background PR-monitoring turn and aborting it.
The server already knows had_active_turn=true at teardown time, so that state appears available for a defensive guard before shutdown/archive is committed.
Activity
THCue commentedon Jul 14, 2026
Additional Windows reproduction/evidence from 2026-07-13 PT.
Environment:
26.707.62119during the initial incident26.707.71524during recovery/repeat incidentObserved sequence:
thread/archiverequest tore down a group of related thread listeners.had_active_turn=true.op: Shutdownfollowed byaborting running task task_kind=Regular.archived_sessions; the parent disappeared from the normal task UI and required recovery by thread ID.26.707.71524.sessions, but a continuation request still resolved the oldarchived_sessionspath and failed with “file does not exist.” The thread DB caught up shortly afterward; a retry then resumed successfully.The public task/session IDs are omitted here but can be provided privately through in-app feedback if maintainers need them.
This suggests more than a sidebar refresh issue:
Expected safeguards:
had_active_turn=true;The task has now been restored, repinned, and resumed, but the interrupted turns were lost.