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

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

• #35099
• #35431

Powered by Codex Action

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

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.

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.

Additional macOS reproduction on a newer Desktop build, with a paused (not completed) Goal and a sanitized read-only state correlation.

Environment

• Codex Desktop: 26.803.41515 (build 6321)
• macOS: 15.5 (build 24F74)
• Architecture: Apple Silicon (arm64)
• Local project thread

Observed behavior

A long-running Goal had accumulated 3h 23m 49s of active Goal time. I clicked Pause, then clicked the composer-level Stop button. After more than 60 seconds:

• the Goal card showed Paused;
• the Stop button remained visible and unresponsive;
• the sidebar continued to show the thread activity spinner;
• the thread did not return to a normal idle/send state.

The inconsistent state survived Desktop process restart/resume.

Sanitized read-only diagnosis

I correlated the affected thread using its persisted paused Goal state and the exact Goal duration visible in the UI. No thread IDs, project names, paths, prompts, file contents, or raw logs are included below.

The persisted Goal row reported:

status=paused
time_used_seconds=12229
updated_at=2026-08-10T12:05:10Z

The sanitized rollout/Desktop timeline was:

2026-08-10T08:41:19.519Z  task_started
2026-08-10T09:05:21.634Z  last completed visible tool output
2026-08-10T09:06:07.339Z  last token_count / recorded turn activity
2026-08-10T12:05:10.963Z  thread_goal_updated status=paused
2026-08-10T12:05:53.774Z  maybe_resume_success latestTurnStatus=inProgress markedStreaming=true

After that task_started, the rollout contains no task_complete, turn_aborted, or turn-level error. All inspected visible tool calls before the stall had completed. Around the pause/Stop action, the Desktop log contains the Goal-state update but no corresponding turn/interrupt entry.

This suggests that the Goal pause was persisted successfully, but the in-progress turn was neither interrupted nor reconciled. On resume/hydration, Desktop continued restoring the stale turn as inProgress with markedStreaming=true.

Expected behavior

• Pausing the Goal should prevent further automatic Goal continuation.
• Clicking Stop should reliably interrupt the current turn and clear the streaming/active indicators.
• If the interrupt cannot be delivered, Desktop should surface an explicit error and a recovery action.
• Restart/resume should reconcile a paused Goal and stale in-progress turn instead of preserving an unusable Stop state.

This appears closely related to the original completed-Goal report, but the distinguishing variant is: the Goal is persistently paused, while its old turn remains in-progress/streaming and cannot be stopped.