### What issue are you seeing? In a workspace with layered AGENTS.md guidance and reusable skills, Codex became locked into a meta-workflow instead of executing an already-approved implementation plan. The user had explicitly specified: - Codex was the primary reviewer/planner, not the implementation worker; - a special high-difficulty workflow was reserved and must run only when explicitly named; - ordinary tasks must not create repeated contracts, freezes, independent reviews, or extra harne

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #35272 *Powered by [Codex Action](https://github.com/openai/codex-action)*

Layered instructions can lock Codex into repeated planning/review meta-workflows with zero implementation

Open 💬 4 comments Opened Aug 2, 2026 by luxueliu

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

In a workspace with layered AGENTS.md guidance and reusable skills, Codex became locked into a meta-workflow instead of executing an already-approved implementation plan.

The user had explicitly specified:

Codex was the primary reviewer/planner, not the implementation worker;
a special high-difficulty workflow was reserved and must run only when explicitly named;
ordinary tasks must not create repeated contracts, freezes, independent reviews, or extra harness stages;
after repeated no-progress actions, the agent must stop.

Despite those instructions, affected sessions repeatedly cycled through stages equivalent to:

problem contract -> freeze -> review -> freeze -> problem contract -> review

The special reserved workflow was treated as globally applicable. The agent repeatedly re-read or reinterpreted rules, but produced no implementation artifact, including failing to complete the smallest initial requested function.

This occurred even after a fresh task was opened and after the user explicitly told the agent to stop repeating the meta-process.

Expected behavior

The newest explicit user instruction must dominate inferred process. A named opt-in workflow must not become a global default.

Codex should stop automatically after a small number of consecutive turns with no new file diff, test result, artifact, or user-visible progress. It should report the conflict rather than reopening planning stages.

This is separate from the hook auto-turn loop reported in #34477, although hook-driven continuation may amplify the impact.

Environment:

OpenAI Codex Desktop 26.727.6591.0 (x64 MSIX)
Windows 10.0.26200.8875
Model observed: GPT-5.6 Sol

No private workspace files or transcripts are attached.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 26 days ago

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

#35272

Powered by Codex Action

xiedongqingxiao-ops · 26 days ago

Severity and production impact

This was not merely an annoying planning loop. The affected sessions caused measurable resource loss and blocked work:

Approximately 80% of the weekly Codex allowance was consumed on 2026-08-01: about 60% in the first failed run and another 20% after the work was reopened/resumed.
A local postmortem estimated more than 500,000,000 tokens across the affected runs; the exact raw count is still unverified.
At least one no-progress segment ran for roughly 35 minutes before manual intervention.
Implementation result: zero planned features completed.
The smallest initial continuation/summary function was still not working.
The user added a temporary supervision harness to recover the agent, but the harness run also produced no usable output.
A separate creative/worldbuilding task depending on this implementation was blocked and had to be moved to another workflow.

This impact is why a hard no-progress/automatic-turn circuit breaker is necessary. The instruction stack may increase context cost, but it must not allow repeated model turns to consume most of a weekly quota without a file diff, test result, or explicit user continuation.

xiedongqingxiao-ops · 26 days ago

Exact rollout reconstruction (replaces prior >500M estimate)

I reconstructed the affected local rollout families using each file's final payload.info.total_token_usage.total_tokens and the child parent_thread_id graph:

Initial ARCH root 019fbc65-...: 11 sessions, 420,775,426 tokens
Reopened ARCH root 019fbd87-...: 5 sessions, 61,684,846 tokens
Harness/recovery roots: 76,001,247 tokens
Original incident total: 558,461,802 tokens
Later failed ARCH-F1 reattempt: 25,544,534 tokens
Cumulative affected/recovery total: 584,006,336 tokens

The original incident corresponds to the user-observed loss of approximately 80% of the weekly allowance (about 60% in the first run and another 20% after reopening). The previous ">500M" statement can now be treated as confirmed and refined to the exact local rollout total above.

xiedongqingxiao-ops · 26 days ago

Arithmetic correction

The exact reconstruction comment above contains one subtotal typo: recovery/harness task families total 76,001,530 tokens, not 76,001,247. The already reported original incident total (558,461,802) and cumulative total including the later failed reattempt (584,006,336) are unchanged.