Skip to content

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

Open

Description

@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:

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

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    on Jul 10, 2026
  2. THCue commented on Jul 14, 2026

    @THCue

    Additional Windows reproduction/evidence from 2026-07-13 PT.

    Environment:

    • Codex Desktop Windows client 26.707.62119 during the initial incident
    • Later client 26.707.71524 during recovery/repeat incident
    • Normal long-running local task, renamed and pinned by the user; not an automation

    Observed sequence:

    1. At approximately 22:35:20-22 PT, one thread/archive request tore down a group of related thread listeners.
    2. Two related regular threads recorded had_active_turn=true.
    3. For both, the logs show op: Shutdown followed by aborting running task task_kind=Regular.
    4. Three rollout files, including the long-running parent task, moved into archived_sessions; the parent disappeared from the normal task UI and required recovery by thread ID.
    5. After unarchiving and resuming, the same parent was archived again at 23:50:52 PT by Codex Desktop 26.707.71524.
    6. The next unarchive briefly left inconsistent state: the rollout file had already moved back under sessions, but a continuation request still resolved the old archived_sessions path 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:

    • archive is accepted while related/descendant regular turns are active;
    • archiving a parent can shut down active descendant work;
    • restore can temporarily expose non-atomic file/index state;
    • a pinned/renamed active task can become hard to discover and require manual recovery.

    Expected safeguards:

    • reject or require explicit confirmation before any archive operation that would affect had_active_turn=true;
    • do not cascade archive shutdown into active descendants;
    • update rollout file location and thread index atomically during archive/unarchive;
    • preserve title/pin visibility and provide an obvious Undo/Unarchive recovery path.

    The task has now been restored, repinned, and resumed, but the interrupted turns were lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions