macOS: completed long Goal task resumes with markedStreaming=true and persistent Stop button

[mmashwani]

Description

The Stop button remains visible in one completed Codex task even when nothing
is running. Fully quitting and restarting the desktop app does not clear it.

This task had completed a roughly four-hour working session with an active
Goal. The Goal completed successfully and was automatically cleared. This has
not happened with any other Goal or task.

Observed sequence

1. Run a Codex task with a Goal for roughly four hours.
2. Allow the Goal and its final turn to complete successfully.
3. Confirm that the Goal is automatically cleared.
4. Fully quit the desktop app with Cmd+Q.
5. Reopen the app and return to the completed task.
6. Observe the composer before submitting another message.

This sequence has not reproduced the problem with any other Goal. The issue has
only occurred in this specific task after its roughly four-hour session, so
these are the observed conditions rather than a deterministic reproducer.

Actual behavior

The composer displays the Stop button even though the task has no running Goal,
turn, terminal, or recorded command process. The button remains after a
complete application restart.

Read-only local diagnosis

The desktop startup log records this successful resume event for the affected
task:

2026-07-27T10:42:18.313Z
maybe_resume_success
latestTurnId=019fa328-ab55-7f82-be9d-4b6d4b0a3f8e
latestTurnStatus=completed
markedStreaming=true

The completed backend state and streaming marker therefore disagree in the
same resume event. Separate read-only checks found:

• no active Goal;
• no attached terminal;
• every turn before the next submitted message was completed;
• none of the command-process IDs recorded for this task still existed.

This suggests that desktop resume or hydration restores a stale streaming state
after the latest turn has already completed.

Expected behavior

The composer should display the Send button whenever the task has no active
turn. Restoring a completed task after an application restart should not retain
stale running-state UI.

Scope

• Reproduces in one long-running task only.
• Has not occurred with any other Goal or task.
• The affected task remains the only known occurrence.
• Task ID: 019f9b08-b2fc-7902-a462-af168f600607

Environment

• Codex desktop version: 26.721.41059 (5848)
• macOS: 26.5.2 (25F84)
• Architecture: Apple Silicon (arm64)
• First observed: July 27, 2026, approximately 5:56 AM CDT

Related reports

• Windows app: completed task remains stuck showing Stop (■) after restart and fork #35099 reports the same completed-task and persistent-Stop mismatch after a
  restart on Windows.
• Codex Desktop threads remain spinning after long gpt-5.5/xhigh turns, compaction, and interruption on macOS #24467 reports latestTurnStatus=completed with markedStreaming=true after
  resuming long macOS threads.
• Windows Desktop 26.715.4045.0: completed threads remain “thinking”; new messages queue locally and cannot start a turn #34026 reports completed backend turns remaining visually active after
  desktop state restoration on Windows.
• Codex Desktop accepts prompt but UI stays stuck in Thinking; Stop fails and turn can become invisible after restart #24287 reports broader macOS session and Goal state desynchronization.

[github-actions]

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

• Windows app: completed task remains stuck showing Stop (■) after restart and fork #35099
• Windows Desktop: reopening a long thread restores an old message instead of the latest content #35431

Powered by Codex Action

[mmashwani]

This is on macOS, so maybe it warrants it's own ticket. The other potential duplicate tickets are for Windows.

[ataira55]

Additional macOS reproduction on a newer Desktop build.

Environment

• ChatGPT/Codex desktop app: 26.721.81911 (build 5973)
• macOS: 26.3 (25D125)
• Architecture: Apple Silicon (arm64)
• Local Codex threads, with multiple threads active in parallel

User-visible behavior

This has occurred repeatedly, not just once in a single task:

• An affected task continues to look active after its latest turn has completed.
• The composer does not accept a new message, so the task cannot be continued from that view.
• Switching away and reopening the task may not clear the stale running state.
• Fully quitting and restarting the desktop app is the only consistently observed recovery, but that is disruptive and potentially unsafe while other local tasks are still running.

Read-only state comparison

A cross-thread status read reported the affected task as idle, with its latest turn completed successfully. The Desktop renderer log nevertheless recorded the following for the same task:

2026-07-31T07:52:34.216Z
maybe_resume_success
latestTurnStatus=completed
markedStreaming=true

Around turn completion, both the primary renderer and the avatar overlay also logged:

error [electron-message-handler] Item not found in turn state itemId=<redacted>

No raw logs are attached because they contain local paths and conversation data. Thread IDs, item IDs, project names, and user paths are intentionally omitted.

Expected behavior

When the latest backend turn is completed and the task is idle, Desktop resume/hydration should clear the streaming marker and immediately enable the composer. Recovery should not require quitting the entire app, especially when unrelated local tasks are still running.

[TiagoNeder]

Additional reproducible variant affecting both Codex Desktop and the Codex VS Code extension, with a reliable workaround.

Environment

• ChatGPT subscription: Plus
• Codex Desktop: 26.727.51351 (build 6119)
• Codex VS Code extension: 26.727.40816
• macOS: 26.5.2 (build 25F84)
• Architecture: Apple Silicon (arm64)

Observed behavior

After a long Goal finished, the same thread continued to show the Pursuing goal banner and its Edit / Pause / Clear / Show full goal controls in both Codex Desktop and the VS Code extension.

Read-only checks disagreed with the UI:

• the model-facing get_goal result was goal: null;
• the local goals_1.sqlite database had no rows in thread_goals;
• the repository/workspace was not involved in the stale state.

Clicking the banner's Clear goal control did not remove it while a response was active. The composer-level Clear control also had no effect. Reloading the VS Code window did not clear the banner, and the same stale Goal state remained visible across both clients.

Reliable workaround

1. Click Edit goal.
2. Change the objective to a short value (tested with finalizar).
3. Save the edited Goal.
4. Click Clear goal.
5. The stale banner is removed successfully.

The original Goal objective, thread IDs, local paths, and conversation contents are intentionally omitted.

Why this seems useful

Editing the objective appears to force a Goal-state write/rehydration that makes Clear work again. Because the same stale banner was visible in Desktop and VS Code while the Goal database was already empty, this looks like a shared thread/Goal hydration mismatch rather than only a renderer cache problem.

Expected behavior

• A completed or cleared Goal should not remain visible when get_goal is null.
• Clear goal should be idempotent and remove stale UI state even when no backend Goal row exists.
• Users should not need to edit/recreate Goal metadata before Clear can succeed.