Long-running tasks keep expanding work instead of converging or stopping
What version of the Codex App are you using (From “About Codex” dialog)?
26.721.41059
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
In one long-running coding task, Codex repeatedly expanded a finite implementation into additional tasks, subagent lanes, review cycles, and verification gates instead of converging. The behavior repeated throughout approximately three days in the same task.
The agent repeatedly reported a small number of remaining steps, but subsequent turns replaced them with new steps. It did not maintain a stable, evidence-backed critical path or clearly expose which changes were still local, which were published, which had passed independent review, and which had reached staging.
The user repeatedly instructed the task to continue autonomously and later instructed it to stop expanding work and publish the current code. Manual intervention was still required to locate a small unpublished diff, prepare an emergency commit-and-push prompt, and move evaluation to a separate thread.
There was no visible crash or single error message. The failure was behavioral: non-converging orchestration, opaque progress, repeated task multiplication, and excessive time, token, and resource consumption relative to the remaining code change.
Observed frequency: once in one long-lived task, with the same failure pattern repeated many times inside that task.
What steps can reproduce the bug?
- Start a Codex App coding task with a finite multi-repository goal, explicit staging-only authority, explicit safety boundaries, and objective completion gates.
- Allow Codex to use subagents and independent review/fix cycles.
- Instruct Codex to continue autonomously until the stated terminal condition.
- After several correction cycles, ask for the exact remaining work and task progress.
- Observe Codex repeatedly report a short remaining list, then create more tasks, review cycles, or gates without showing that they close a newly failed acceptance criterion.
- Instruct Codex to stop expanding the task and publish the current task-owned code.
- Observe that manual rescue is needed to identify the dirty worktree, preserve the current diff, and force an immediate branch/PR snapshot.
This has not yet been reproduced in a new clean task.
Session ID: 019f8930-2743-7983-9c52-bdd1af78e094
What is the expected behavior?
Codex should maintain one visible, evidence-backed critical path and reduce the remaining work after each correction cycle.
When a review or test fails, Codex should name the exact failed acceptance criterion, the smallest required fix, and the maximum correction-cycle count. It should not create new tasks or agents unless they are necessary to close that named failure.
The task UI should clearly distinguish unpublished local code, pushed branches, open PRs, approved heads, staging deployments, automated QA, and manual QA.
After repeated non-convergence or a configured time or cycle limit, Codex should stop and offer an explicit choice to publish the current task-owned work, continue one bounded fix, or end the task.
When the user says to publish the current code immediately, Codex should preserve the existing diff, create a normal commit, push to the existing branch or a safe snapshot branch, update or open a draft PR, report the immutable SHA and PR URL, and stop without starting another review or QA cycle.
Additional information
Codex thread source: long-running private coding task with subagents and review/fix loops.
macOS:
- ProductVersion: 26.5.2
- BuildVersion: 25F84
No application crash log or visible fatal error was observed.
The unpublished state located during manual recovery was small: three task-owned files with approximately 151 insertions and 9 deletions on an existing tracked feature branch. This private repository detail is intentionally generalized in the public report.
Full private thread context can be supplied to OpenAI diagnostics if requested.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I ran into a similar problem with long-running tasks: I had no reliable progress to follow and no clear source of truth showing what was finished, what remained, what the agent was currently working on, or what decisions had been made.
I addressed it using hooks, persistent files, and skills, and later packaged the workflow as an MIT plugin called Nightshift (source).
The main idea is similar to an execution plan, but the plan becomes a persistent punch-list file instead of living only in the conversation context. Each completed item is visibly ticked, so opening the file shows the current progress and remaining work. Decisions are recorded with the default taken and its reasoning, and the working contract above the items is preserved throughout the shift. The stop hook keeps the session from quietly ending while boxes remain open.
You can give it a try and see whether this persistent source of truth helps with the progress-tracking problem you reported.