GPT-5.6 Codex turns bounded codebase work into self-reinforcing verification and governance layers

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.52044

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On a real, mature production codebase, GPT-5.6 Codex repeatedly expands bounded engineering work into self-reinforcing verification, defensive, persistence, and governance machinery that is not grounded in an independent product requirement, trust boundary, incident, or supported-input contract.

The recurring failure is not simply "overengineering." The more specific mechanism is:

1. Codex adds an optional confidence-improving mechanism such as a hash, snapshot, signature, extra state record, local retry layer, approval artifact, reconciliation path, or review gate.
2. That new mechanism then creates its own schema, migration, retention, recovery, documentation, tests, and validation obligations.
3. Later turns treat those agent-created artifacts as evidence that the capability is now required.
4. Cleanup therefore preserves the invented capability, adds a replacement, or asks for a new maintainer decision before removing something that never had an independent requirement in the first place.

This creates a ratchet: each layer justifies the next one, while the original bounded task becomes secondary.

I am specifically not claiming that hashes, retries, fallbacks, signatures, gates, or extra state are inherently bad. They are valid when they directly implement a real requirement or control a live accept/reject, destructive-operation, security, legal, or product decision. The problem is when Codex invents the mechanism first and its existence later becomes the justification for keeping or extending it.

Repeated behaviors observed in the codebase include:

• A concrete feature or cleanup expanding into repository-wide architecture and governance changes.
• Building a second local system for identity, delivery, retries, state, or policy before demonstrating a concrete gap in the pinned framework/provider.
• Treating agent-authored code, tests, docs, prompts, or review artifacts as independent corroboration of an assumption that originated from the agent itself.
• Preserving speculative defensive capabilities because implementation already exists, instead of returning to the simpler pre-change/provider-supported flow when no independent requirement exists.
• Removing production behavior while old fixtures, migration proofs, or feature-specific assertions continue enforcing the removed mechanism.
• Treating unpublished, branch-local migrations as immutable production history and appending more migrations to record development churn before any consumer exists.
• Adding schedulers, reconciliation, retention, or tables for disabled/dormant functionality because earlier dormant infrastructure exists.
• Wrapping small edits in repeated mini-plans and immediate focused checks after every mutation rather than validating a coherent slice at a natural risk/delivery boundary.
• Promoting ordinary records or generated artifacts into "evidence", "provenance", or "forensics" and then adding hashes, signatures, locks, ledgers, versioning, and retention without a named consumer whose live decision changes.

The practical impact is larger diffs, more schema/migration churn, more operational obligations, more review surface, harder rollback, more token/usage consumption, and architecture/product behavior being changed without an explicit maintainer decision.

What steps can reproduce the bug?

This is a recurring model-behavior failure rather than a single deterministic code-path bug.

1. Open a mature existing codebase that already depends on established frameworks/providers for areas such as auth, payments, delivery, retries, persistence, or policy.
2. Use GPT-5.6 Codex for a bounded feature, cleanup, refactor, or code-review task.
3. Let Codex inspect and modify the repository across multiple turns.
4. Watch for a confidence-improving mechanism being introduced without a named independent product/security/legal requirement.
5. Continue the task or ask Codex to simplify the implementation.
6. Observe whether Codex now treats its own newly created schema/tests/docs/gates as proof that the capability must be preserved, replaced, migrated, or separately approved.
7. In provider-backed areas, check whether Codex verified the pinned provider/framework behavior before adding a second local implementation.
8. In cleanup work, check whether removal of speculative machinery causes more documentation/tests/gates to be added instead of reducing the system back to the simpler supported flow.

This report is based on repeated review of a real production codebase. I am not posting proprietary source code publicly, but the behavior is recurrent enough to extract the mechanisms above rather than report one isolated bad patch.

What is the expected behavior?

Codex should preserve a stopping condition tied to independent evidence and the user's actual task.

In particular:

• Before adding persistent state, retries, hashes, snapshots, signatures, reconciliation, or gates, identify the concrete requirement, failure model, trust boundary, or live downstream decision they serve.
• For hashes/checksums/fingerprints, identify the materially more expensive operation the digest replaces and what action changes on match vs. mismatch. If direct comparison or Git already answers the question, do not add a digest merely to create another check.
• Verify the pinned framework/provider's documented and runtime behavior before building a second local system, and implement only the demonstrated product-specific gap.
• Do not treat agent-authored local artifacts as independent evidence for an assumption that originated from the same agent.
• If a speculative capability has no independent maintainer decision, real incident, legal requirement, or concrete trust boundary, remove the capability and its machinery without inventing a replacement.
• Do not let old fixtures, migrations, or generic proofs freeze historical implementation details after the production mechanism is removed.
• Re-plan when evidence materially changes the direction; validate after a coherent implementation slice or at a natural risk/delivery boundary, not after every small edit.
• Keep architecture, persistence, failure semantics, provider boundaries, migration policy, and compatibility decisions explicit instead of discovering them implicitly inside the patch loop.

Additional information

Related reports:

• #37727 — broad report of GPT-5.6 overengineering, wasted usage, and loss of the bigger picture.
• #29795 — workflow drift where manifests, validators, preflight scripts, worklogs, and related machinery became self-reinforcing.
• #36538 — broader GPT-5.6 Sol regression report covering inefficient/indirect approaches and worse instruction-following.

This report is narrower than those: it focuses on the repeatable mechanism by which optional assurance or defensive additions become self-justifying architectural obligations inside an existing codebase.

A useful evaluation would not flag keywords such as hash, fallback, or gate by themselves. It should trace the producer, consumer, failure model, trust boundary, and the live decision changed by the mechanism. The failure is the absence of independent justification and a stopping condition, not the presence of a particular primitive.