Codex Desktop stops prematurely after context/task handoff instead of continuing work

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

• #32922
• #32931

Powered by Codex Action

I have the same issue (model gpt-5.6-terra medium):

<...>
Codex: Chunk 1 (tasks 1.1–1.3) is complete and fully gated. ...
Me: Explain me, why did you stop?
Codex: I stopped prematurely—there was no technical blocker or required human gate. I had completed only the first of four planned chunks, then incorrectly returned a status update instead of continuing the autopilot loop into chunk 2. The workflow explicitly requires continuing until a real hard stop.
Me: Continue, please
<...>
Codex: Continuing. Chunk 2 has now implemented and gated. <Actually, it stopped>
Me: Continue
<... And this pattern again and again...>

Who can tell, is it expected behavior to force us use /goal command or a bug?

Same issue here. Windows, Codex Desktop 26.727.6591.0. Happens repeatedly across 3 separate conversations: during a long multi-step task the agent sends only a status text (e.g. "马上做/正在做") and ends the turn without calling any tool. It resumes only after the user sends another message ("?"/"继续"). No permission prompt, no error. Expected: keep executing until done or a real blocker. Happy to provide session logs.

I'm also seeing this behavior very consistently in the current ChatGPT/Codex desktop app on macOS, and it became significantly worse within the last ~24 hours after a recent desktop update.

Environment:

• MacBook Pro 16-inch (2021)
• Apple M1 Pro
• 32 GB RAM
• macOS Tahoe 26.2
• ChatGPT Plus
• ChatGPT desktop version: 26.810.52044

Thread session IDs:
01a00856-d54e-7221-8669-c91b61e33172
01a00348-8da0-7593-924d-02b0fdf60f6c

The failure pattern during longer Goal/agentic tasks is:

1. The agent is actively working and making normal progress.
2. Context compaction/handoff occurs.
3. Immediately afterward, the turn abruptly stops even though the original task is still incomplete.
4. There is no request for clarification, approval, or other user input.
5. If I send "continue" or another short nudge, the agent immediately resumes the work it was already supposed to be doing.

So the state transition is effectively:

active task → compaction/handoff → unexpected turn termination → user sends "continue" → task resumes normally

This is particularly disruptive for long-running Goal mode workflows because compaction should be an internal continuation mechanism. Instead, I now have to monitor the session and manually restart the agent whenever compaction happens.

I'm seeing a related issue when starting new desktop sessions as well: the first substantial prompt frequently begins and then abruptly stops, requiring me to submit the prompt again before the agent proceeds normally.

I've completely deleted the ChatGPT desktop app, downloaded a fresh copy, and reinstalled it. The behavior persists.

I did not experience this regularly before, and the frequency increased sharply following the recent desktop update.

Expected behavior: if the active goal is unfinished and compaction/handoff completes successfully, the agent should continue execution automatically unless it encounters a genuine blocker that actually requires user input.

The “handoff/compaction happened, then Codex stopped as if the task were new even though work was unfinished” pattern is a useful recovery-continuity case for codex-rescue. I’m field-testing the tool against real sessions to see what durable evidence survives the transition and whether it can produce a bounded continuation handoff without pretending unknown work completed.

If you still have an affected local session, could you run:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

If doctor finds an interrupted state and you want to exercise recovery:

codex-rescue salvage --latest --fork
codex-rescue verify <rescue-id>

The original rollout remains read-only and unknown side effects are not auto-replayed. Please share sanitized output/versions/exit codes only—no raw session/DB files, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue

Corroborating this on the current macOS desktop build, with a subagent-specific symptom.

Environment

• ChatGPT/Codex desktop: 26.814.41407 (bundle 6720)
• Bundled Codex runtime: codex-cli 0.148.0-alpha.15
• macOS 26.5 (25F71), Apple Silicon (arm64)
• Observed repeatedly as of 2026-08-20

Observed behavior
In a very long-running local task with extensive tool and subagent activity:

1. Automatic context compaction reports completion.
2. Subagents may continue working and can even finish their assigned work.
3. The parent/primary task does not resume orchestration, issue further tool calls, request approval, or identify a blocker.
4. A short user nudge such as “continue” immediately wakes the parent, which then resumes the already-active task and can collect/continue the subagent work.

This has recurred multiple times and can silently stall multi-hour or multi-day work until the user notices. The subagents continuing while the parent is idle suggests a lost parent continuation/turn-scheduling transition after successful compaction, rather than compaction itself hanging or the task waiting for an approval.

Expected
After successful compaction, an unfinished parent task should automatically resume orchestration. If continuation is impossible, the app should expose a specific blocker or required input.

Current workaround
Send a minimal follow-up message (“continue”). This reliably resumes the parent in the observed cases, but requires active supervision.

Only the version/OS/architecture metadata above is included. No thread IDs, raw logs, prompts, repository data, local paths, credentials, or stable machine identifiers are attached.

+1.
/goal stops and I have to type /goal resume.

Additional quantified data from the affected macOS Codex Desktop environment:

Current environment

• Codex Desktop for macOS: 26.818.22352 (6872)
• Observed through August 21, 2026
• The problem continues on the current installed Desktop build

Aggregate local-history review

I performed a read-only review of recent long-running Codex task histories. The review was limited to high-activity task candidates and excluded explicitly named automations and internal review runs.

• 94 recent long-running task candidates inspected
• 42 tasks contained at least one context compaction
• 223 context-compaction boundaries observed across those 42 tasks
• 62 compactions, or approximately 27.8%, matched the strongest “lost continuation” pattern:
• no additional tool activity after compaction; and
• the turn ended with a generic readiness response such as “What would you like me to work on?” even though a request was already active

The 27.8% figure is a pattern count, not a claim that every one of those events was manually adjudicated as a product failure. However, manual review of representative cases confirmed repeated genuine failures involving already-specified multi-step work.

In those confirmed cases:

1. The complete user request was durably present immediately before compaction.
2. Context compaction completed rather than hanging.
3. The resulting turn was recorded as completed.
4. Instead of continuing, the parent responded as though it had received no task.
5. Sending an ordinary follow-up such as “continue” immediately caused the same task to resume.

One representative long-lived task experienced 16 compactions:

• 12 resumed with substantive tool activity
• 3 clearly lost the active request and returned a generic readiness question
• 1 followed an instruction-only transition without tool activity

This suggests that compaction itself is not consistently failing. The failure appears to be intermittent continuation/orchestration behavior after a successful context transition.

Why /goal resume is not my workaround

Another commenter mentioned using /goal resume. I am reproducing this in the native macOS Codex Desktop app, not in the interactive terminal TUI.

The Desktop composer does not expose an equivalent /goal resume command for me. Typing / does not provide the CLI/TUI goal-control workflow, so I cannot use /goal resume to reactivate the task. My available workaround is to send a normal user message such as “continue,” which consumes another interaction and requires me to supervise the task.

This appears related to the Desktop/CLI goal-control gap discussed in #22049 and the lack of noninteractive goal controls discussed in #31783.

Persistence boundary

The affected task histories generally remain readable and indexed. This does not look like widespread session-file corruption or missing history. The problematic turns frequently contain:

• a successful compaction event;
• retained replacement history;
• a normal-looking completed-turn event; and
• a semantically incorrect generic readiness response.

That distinction may matter diagnostically: the persisted structure can look complete even though the parent failed to continue the unfinished objective.

No raw rollout files, task IDs, prompts, private paths, repository data, credentials, account information, or stable machine identifiers are included in this report.

Live reproduction while preparing this comment

Rather ironically, this exact task reproduced the bug while I was preparing this update in Codex Desktop. After I approved the public comment, the task announced that it was posting it, then context compaction occurred. The next response was the generic “I’m ready. What would you like me to handle?” The comment was not posted, and I had to send another message to resume the already-approved action. So this comment itself required a manual post-compaction nudge.

In addition to my previous message

I'm using codex-cli 0.147.0 under MacOs. I do not use /goal command for some reasons. I see that gpt-5.6-terra has a tendecy to stop in a middle of a multi-step task where I expect continuation (as I described it in my message above). At the same time I observe that gpt-5.6-sol works more stable in such scenarios. It doesn't stop till the end of the scenario or a required user interaction.

As result, in my current setup I typically use gpt-56-sol lite as an orcestrator and gpt-5.6-terra medium as workers (subagents), and it gives quite stable workflow execution.

In particularly it means that I would recommend to mention a model you use describing issues of such kind.

I have the same issue. A fairly large task will be regularly stopped for no apparent reason. No question from the agent either. It states where it has stopped and how much work is left (kinda like a status update) - but without any reason to actually stop. Am using Luna 5.6.