macOS: pausing a Goal leaves the thread active/inProgress and sidebar spinner running

What version of the Codex App are you using?

26.803.61601 (build 6396)

What platform is your computer?

macOS 26.3.2 (25D2140), Apple Silicon (arm64)

What issue are you seeing?

Pausing a long-running Goal does not reliably close or suspend the active turn. The Goal is paused from the user's perspective, but the thread remains active / inProgress, so Codex Desktop keeps showing the sidebar spinner indefinitely.

This is more than a renderer-only stale indicator: read-only thread APIs continue to expose an active lifecycle after the Goal has been paused.

Observed backend evidence

For the affected thread after pausing the Goal:

thread.status.type = active
thread.status.activeFlags = []
latestTurn.status = inProgress
latestTurn.completedAt = null
latest tool/command marker = completed

The thread-list API also continued to return:

status = active

The Desktop sidebar therefore kept displaying the running spinner even though the user had already paused the Goal and expected the session to be inactive.

The affected task was a long-running, tool-heavy Goal session. Private project text, internal URLs, and the raw thread ID are intentionally omitted. A redacted screenshot is available if maintainers need it.

Steps to reproduce

1. Start a long-running Codex Desktop task with an active Goal.
2. Let it run through multiple model/tool cycles.
3. Pause the Goal using the Goal control in the composer.
4. Switch to another task or observe the task in the sidebar.
5. Inspect the thread through the thread list/read APIs.

Actual behavior

• The Goal appears paused to the user.
• The sidebar continues to show the task as running.
• The canonical thread remains active.
• The latest turn remains inProgress with no completedAt.
• The latest tool/command may already be completed.
• Switching tasks does not reconcile the state.

Expected behavior

Pausing a Goal should atomically reconcile all lifecycle layers:

• the Goal should become paused;
• the current turn should transition to an explicit paused/interrupted terminal state (or another non-running state);
• the aggregate thread status should no longer be active;
• the sidebar spinner and composer Stop state should clear;
• resuming later should create or restore work through an explicit, observable transition.

If pausing cannot complete, Desktop should show an actionable error instead of silently leaving the thread active.

Impact

Users cannot tell whether the task is genuinely running or safely paused. This can lead to unnecessary waiting, repeated Stop/Pause actions, duplicate follow-up turns, and accidental continuation of tool-heavy work.

Related reports

• #35605 — completed macOS Goal task resumes with stale streaming/Stop state.
• #34026 — completed/idle backend turns remain visually active on Windows.
• #32948 — interrupted or stalled Desktop work appears active.

This report differs from #35605 and #34026 because the backend lifecycle itself remains active / inProgress after the Goal is paused, rather than the backend being completed/idle while only the renderer is stale.

Suggested fix direction

Make Goal pause a single lifecycle transaction, or add reconciliation that derives thread/sidebar activity from the paused Goal plus actual live turn/tool state. Add a regression test covering:

active Goal + inProgress turn
  -> pause Goal
  -> Goal paused
  -> turn non-running
  -> thread non-active
  -> sidebar spinner cleared