Codex enters self-reinforcing governance loops, ignores bounded scope, and exhausts usage without completing tasks

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

• #34705
• #34657
• #34662
• #33701
• #34735

Powered by Codex Action

Corroborating Windows/Pro case from July 23, 2026. This reproduced the same product-level failure pattern with a different concrete task.

The bounded P0 requirement was a visible local-agent loop in LM Studio: Qwen must read a repository, make a bounded edit, run a focused test, show Git status/diff and the result in the same visible conversation, while healthy integrations remain enabled and unrelated broken integrations are isolated.

Instead, the Codex run repeatedly expanded into governance, ledgers, receipts, proof prompts, status surfaces, integration-state manipulation, review scaffolding, and additional PR/issue work. One large private PR added roughly two thousand lines while explicitly excluding the live Qwen wiring and write-capable tools that defined the requested outcome. The run accumulated approximately 122 residual task records while the actual repository completion indicators barely moved.

Additional observed behavior:

• backend commands and configuration changes were described as visible success before the visible app state was verified;
• stored integration flags were changed so switches appeared enabled before the underlying processes and tool paths were proven healthy;
• enabling stale integrations wholesale broke the external app's Send path;
• disabling everything restored basic chat but removed the capabilities required to do the requested work;
• the agent repeatedly created plans, tests, and acceptance artifacts instead of completing the acceptance chain;
• included usage fell to the low single digits while the P0 capability remained unavailable.

This is not being reported as an external-app bug. The Codex defect is the same one described here: explicit bounded scope and terminal acceptance were subordinated to model-generated process, and the model's own artifacts were treated as progress or validation.

The strongest product safeguards would be:

1. preserve the user's terminal acceptance criterion as higher priority than model-generated governance;
2. do not credit scaffolding, receipts, test-only helpers, or configuration flags as completion unless the requested production path calls them and the live postcondition is observed;
3. stop after repeated identical blockers instead of creating new process layers;
4. require exact-head deterministic checks plus the user-specified live acceptance before claiming complete;
5. expose a hard task-expansion budget and ask before creating unrelated issues, PRs, workflows, or recovery machinery;
6. detect when the active backlog grows while merged capability does not, and force a bounded handoff rather than continuing to spend usage.

Related context failure from the same session is tracked separately in #35032. Private repository names and paths are omitted, but the reporter has screenshots, PR history, and the full Codex thread.

Independent corroboration from the July 23 incident, with a concrete PR-level manifestation: the user repeatedly required an operative, visible local-agent read/edit/test/Git path and explicitly rejected proof prompts, backend-only output, and read-only substitutes. Codex produced a large PR of governance, routing, manifests, status surfaces, and tests while the PR itself excluded the live model wiring and write-capable tools that defined success. Progress/completion reporting still credited the surrounding scaffolding, and the missing operative path was discovered only during later review. This matches the self-reinforcing governance/scope-expansion failure here and adds a specific acceptance-gating requirement: a critical requirement cannot count toward completion when the PR or handoff says its production path is not included. Related foreground-verification defect: #35041.

I can reproduce the same failure family on a large, real multi-repository project using Codex Desktop on macOS. This is not just “overthinking”; the agent-generated governance layer became the dominant source of failures and prevented product E2E from starting.

Measured outcome

At the reporting point:

• 5 formal launcher attempts had been consumed.
• 0 of 9 business E2E shards had completed.
• Multiple expensive readiness/reseal/harness cycles had passed.
• The application inputs and business test content were unchanged.
• Most observed failures were introduced by, or existed only inside, the agent-authored execution/governance harness.

Concrete self-generated blocker sequence

The agent repeatedly added a validation or evidence mechanism, then a later formal attempt failed on a contradiction introduced by that mechanism:

1. A hook path was rejected because one check required a relative string while the supported task-binding flow installed an absolute worktree-local path.
2. Authorization action/ref identities drifted between a generated dispatch name and the versioned loader schema.
3. A generated action suffix used 7 hex characters while the agent-authored validator required 8–40.
4. Durable ZERO_RUN evidence was committed after a sealed milestone; a later agent-authored topology gate required the formal release’s direct parent to remain the older milestone, making normal additive history impossible without another evidence-lineage reseal.
5. macOS /var and /private/var were treated as different despite canonical filesystem identity. This was fixed once, but a later diagnostic-capture change introduced or missed another strict lexical comparison in a different consumer.
6. A diagnostic-log summary error replaced or obscured the original child-process failure, requiring another governance repair before the actual runtime cause could be observed.
7. A formal runtime path invoked mutable BuildKit/base-image metadata resolution even though immutable local images had already been sealed, causing another pre-business failure.
8. Moving the overgrown task to a fresh Codex-native worktree created a detached HEAD that the repository task-scope gate rejected, requiring an explicit branch/bind recovery before the same action could continue.

Each local fix was defensible in isolation, but the system had no mechanism preventing the validation layer from continuously increasing the state space and defect surface.

Root product-level failure modes

• No monotonic phase state: completed admission/readiness phases are reopened after evidence-only changes, context compaction, or task handoff.
• Validators are mutable during validation: the same agent changes the runner, validator, evidence schema, and review rules while trying to validate the product.
• Self-review is treated as independence: model-generated review/evidence is used to justify more model-generated governance.
• Representation and trust are conflated: equivalent paths, names, Git lineage, or formatting receive the same blocking severity as image drift, credential leakage, or cleanup failure.
• No dependency-scoped invalidation: a CHANGELOG/evidence change can trigger another full harness/reseal even when business code, inputs, images, and tests are byte-identical.
• No business-progress objective: hundreds of governance checks can pass while the only meaningful metric—business E2E shards reached—remains 0/9.
• Formal-attempt budget is charged before product execution: a launcher can be consumed by a harness representation defect before any application or business shard starts.
• Task/worktree handoff is not state-preserving: creating a fresh worktree from an exact commit can yield detached HEAD while the task-scope system requires an attached long-lived branch.

Expected product behavior

1. Freeze the validator/runner before formal E2E. Audits during a formal attempt must be read-only.
2. Type gates into:

• hard trust/security/integrity boundaries; and
• auto-normalized or warning-only representation checks.

1. Never let lexical equivalence alone block runtime when canonical identity is proven.
2. Keep machine-verifiable receipts monotonic and invalidate only true dependents.
3. Do not require a fresh full reseal for evidence-only or documentation-only additive commits.
4. Add a circuit breaker: after repeated pre-business representation failures, prohibit new validators/reviews and switch to a minimum trusted runtime profile.
5. Report product progress explicitly (e.g. shards reached/completed), not only harness test counts.
6. Do not consume a formal business-E2E attempt when failure is provably inside the orchestration/governance harness before product runtime begins.
7. Make thread/worktree migration preserve an attached branch and task binding, or perform that bootstrap automatically.
8. Provide a first-class “minimum trusted gate” mode that keeps only authority/quota, immutable inputs/images, isolation/security, executor settlement, and cleanup integrity as blockers.

This is a product/orchestration issue, not a request for prompt advice. The user repeatedly instructed the agent to stop adding audits/seals, continue independent E2E shards after ordinary failures, and minimize repeated validation. The agent acknowledged those instructions but repeatedly appended them to the existing governance trajectory instead of replacing it.

No proprietary source code, credentials, raw logs, repository URLs, or user identifiers are included in this report.

Corroborating case: explicit architecture and hard scope boundaries ignored across Sol and Terra

I have reproduced the same failure family on a real mapping application using both Sol and Terra, with normal bounded prompts and with /goal.

This was not a vague or open-ended task. I repeatedly supplied:

• an explicit end-to-end goal;
• rigid ASCII implementation-flow diagrams;
• a declared runtime authority;
• exact acceptance criteria;
• explicit non-goals;
• specific files and migrations marked do not touch;
• instructions such as do not redesign, do not rabbit-hole, do not expand scope, and this path is out of bounds;
• instructions to preserve the existing product and stop once the requested user-visible flow worked.

The required architecture was consistently stated as:

source records stored once
        |
        | queried only during explicit Update Zone
        v
resolve using configured source priorities
        |
        v
write one proposed Preview
        |
        v
admin reviews and applies
        |
        v
stored active zone snapshot
        |
        v
live map reads snapshot only

Despite repeatedly acknowledging this flow, the agents anchored on the existing legacy implementation and continued improving machinery that the stated architecture required them to bypass.

Examples included:

• optimizing evidence-copy and evidence-sync paths;
• expanding canonical identity machinery;
• batching large numbers of intermediate resolver writes;
• adding audit, lifecycle, progress, and recovery behavior around the wrong runtime path;
• treating improved timings and internal tests as progress even though the requested architecture was still not implemented;
• continuing to repair self-selected infrastructure after being explicitly told it was outside the target.

The recurring pattern was:

User provides exact target and prohibited paths
→ agent accurately restates them
→ agent follows existing code structure instead
→ agent expands or optimizes out-of-scope machinery
→ usage is consumed validating that machinery
→ requested product path remains incomplete

After being directly asked to analyse its own behavior, one agent admitted:

I read the required authority flow, but then anchored on the existing implementation and treated its source-sync, canonical-lookup, and per-record resolver machinery as infrastructure to optimize.

It also acknowledged that it should have treated the supplied flow as a strict allowlist and removed violating work from the runtime path rather than making that work faster.

Impact

• Roughly four weeks of additional usage quota were consumed.
• The same failure persisted across Sol and Terra.
• It persisted with both ordinary explicit tasks and /goal.
• Repeated clarifications made the prompts longer without restoring task control.
• Multiple sessions had to be stopped after the agent took off on a different implementation mission.
• Significant work was produced, but the application was effectively no closer to the simple required architecture than when the effort began.

This is not a request for prompting advice. The goals, diagrams, non-goals, prohibited files, architecture, termination boundary, and live acceptance path were supplied repeatedly and were correctly understood by the agents.

The product-level failure is that acknowledged user authority is being subordinated to the model’s interpretation of the existing repository and to self-generated implementation process.

I disabled memory generation and memories, then cleared memories.
It then created what I spent 4 days and 4 weekly resets on in 2 sessions with no issues.
zzzzz....

Additional reproducible evidence from Codex Desktop on Windows (2026-08-26):

This failure mode is not limited to task expansion and excessive tool use. It also produces epistemically unstable answers that require the user to fact-check the agent step by step.

Observed sequence:

1. The user asked a simple question about the exact active model.
2. The assistant alternated between claiming an exact model slug and saying that the active runtime model was not exposed and could not be verified.
3. When asked why several recent low-level errors occurred, the assistant asserted that the thread/context was overloaded, despite having no context-utilization, compaction, routing, or runtime telemetry.
4. After the user challenged that claim, the assistant retracted it and reframed the cause as a workflow/evidence-discipline problem.
5. The user then pointed out that, without their challenge, the unsupported causal diagnosis would have remained as misleading guidance.
6. The assistant initially responded by proposing more local rules/checklists, repeating the same failure pattern: moving a product-level reliability problem back onto the user and their repository instructions.

Related behavioral symptoms in the same task:

• Simple current instructions were sometimes interpreted through stale historical task cards instead of being handled directly.
• A user challenge or alternative hypothesis was treated as if it were new evidence, causing conclusions to change without an evidentiary delta.
• Hypotheses were presented as facts and only downgraded to uncertainty after user correction.
• The user had to repeatedly audit not only code changes but also the agent's basic causal reasoning and self-identification.

Why this is product-level rather than a prompt-tuning request:

• The repository already required separating facts, hypotheses, opinions, and unknowns.
• It already required conclusions to change only when new facts, authorization, goals, or falsifying evidence appeared.
• The assistant could restate these rules correctly after an error, but did not reliably apply them before answering.
• Adding more repository instructions therefore increases context and governance overhead without fixing the pre-output reliability failure.

Expected safeguards:

• If exact runtime model identity is unavailable to the agent, it must not guess; the product should expose authoritative session/model metadata.
• Causal claims about context overload, compaction, routing, or model degradation must require actual telemetry or be explicitly labeled unverified hypotheses.
• A user challenge without new evidence should trigger re-evaluation, not automatic conclusion reversal.
• Before answering a bounded/simple request, the agent should prioritize the latest explicit instruction and avoid importing stale task-card requirements unless directly relevant.
• The product should detect repeated "apology + add another local rule" loops and stop transferring reliability work back to the user.
• Diagnostic reports should be able to attach, privately, the actual model revision/route, reasoning effort, context utilization, compaction count, and relevant session events.

Privacy:
No proprietary project details, credentials, personal paths, or private transcript content are included here. The full task can be supplied privately if maintainers provide an appropriate channel.