Codex Desktop archives and aborts a regular task while it is monitoring an open PR

Open 💬 1 comment Opened Jul 10, 2026 by qfennessy

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_archived tool 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:

  1. Start a normal Codex Desktop task that creates or works on a pull request.
  2. Keep the task active in a PR follow-through loop, polling CI/review state with a long-running wait tool call.
  3. Desktop performs an archive/cleanup sequence for nearby completed tasks.
  4. The still-running task receives thread/archive even though the server records had_active_turn=true.
  5. 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/archive should reject or require explicit confirmation when had_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:

  • #19742 covers automation runs that are immediately auto-archived. This report is a regular user task, not an automation.
  • #25713 and #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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗