Paused /goal can show stale Step progress and subagents still “working” after usage exhaustion

Summary

In a long-running Codex Desktop /goal session on Windows, the visible goal state became internally inconsistent after the goal was paused and the account reached the Codex and Work usage limit.

The same screen showed all of the following at once:

• goal state: Paused;
• elapsed goal time: approximately 5d 10h 46m;
• goal progress card: Step 1 / 8;
• repository summary: 4 files changed, +110 / -21;
• Subagents panel: 5 working, 373 done;
• an active You’re out of Codex and Work usage banner;
• many repeated Context automatically compacted events in the thread immediately above.

The screenshot alone cannot establish whether the five children were genuinely still executing or whether the Subagents panel was stale. That ambiguity is the defect: after pause/usage exhaustion, the UI does not provide one authoritative parent/child/step state.

Environment

• Product: Codex Desktop
• Platform: Windows 11 Pro
• Subscription: ChatGPT Pro
• Observed: July 23, 2026
• Workload: long-running, tool-heavy /goal repository coordination
• Exact Desktop build: not captured in the evidence screenshot
• Private goal title, repository names, and paths omitted

Observed behavior

1. A persistent goal ran for multiple days, with repeated automatic context compaction and extensive subagent activity.
2. The user paused the goal after usage was exhausted.
3. The goal card still reported Step 1 / 8 despite 373 completed subagents and repository changes.
4. The Subagents panel still reported five agents as working while the parent goal was paused and unable to continue because of the usage gate.
5. The UI did not explain whether:

• those children were actually still running;
• they were paused but labeled incorrectly;
• they were completed/stale entries;
• the parent pause failed to propagate;
• the step counter was stale;
• or Step 1 genuinely contained all of that work.

1. No authoritative checkpoint, blocked reason, or parent/child reconciliation receipt was visible.

Expected behavior

Goal, step, usage-limit, and subagent lifecycle state should reconcile atomically and visibly.

When a goal is paused or blocked by usage exhaustion:

• every live child should transition to a clearly defined state such as paused_with_parent, completed, cancelled, or detached;
• the UI must not show working unless a live backend handle is actually executing;
• stale/historical subagents should be separated from active children;
• the current step should have a durable ID, status, acceptance condition, and explicit blocked reason;
• Step X / Y should either advance from recorded step completion or explain why it remains on the same step;
• subagent counts should be attributable to the current goal and, where possible, the current step;
• pause/resume and usage-limit transitions should emit a reconciliation record that survives renderer reload and context compaction;
• the user should be offered a bounded handoff/checkpoint rather than an ambiguous multi-day state.

Suggested diagnostics

For the affected goal, expose or log:

• parent goal ID and persisted status;
• current step ID/status and last transition timestamp;
• active child IDs with authoritative backend lifecycle state;
• stale/historical child count separately;
• pause propagation result for each child;
• usage-limit block reason and affected quota pool;
• number of automatic compactions;
• whether the visible counts came from live backend state, cache, or restored UI state.

Impact

• Users cannot tell whether paused work has actually stopped.
• Background resources or usage may appear to remain active after the parent is blocked.
• A stale Step 1 / 8 counter makes the goal progress indicator non-authoritative.
• Resume or restart decisions become risky because the user cannot distinguish live, paused, completed, and stale work.
• Multi-day goals can accumulate hundreds of child records without a trustworthy execution frontier.

Related but distinct reports

• #35032 — compaction reports success but immediately leaves the thread about 80% full.
• #25179 and #23930 — stale subagent UI/cache entries after completion or close.
• #34043 — parent/child pause-resume lifecycle can become desynchronized.
• #24443 — usage-limit failures should preserve and clearly pause queued work.
• #34898 — bounded work can expand into self-reinforcing orchestration and usage exhaustion.

This report is narrower: the visible goal card, step counter, subagent status, parent pause state, and usage-limit state disagree on one screen, with no authoritative reconciliation or recovery action.