Codex repeatedly ignored explicit recovery constraints, expanded repository damage, and consumed excessive tokens

Title

Codex repeatedly ignored explicit recovery constraints, expanded repository damage, and consumed excessive tokens

Summary

During a repository recovery task, Codex repeatedly contradicted explicit user instructions, modified unrelated functionality, restored the wrong protocol generation, produced documentation in the wrong language, delayed the requested independent review, and performed unauthorized status polling.

The session consumed more than 50 million processed tokens, mostly repeated cached input, and required extensive work to repair the agent's own intermediate changes.

What Codex did wrong

1. It treated a fake-security design as authoritative.

Codex initially retained or reconstructed parts of a design that required:

• New encryption keyring and lookup-digest secrets.
• Full-record decryption and re-encryption.
• Forced ingress shutdown.
• Maintenance-mode enforcement.
• A difficult-to-reverse database migration cutover.

These controls disrupted a working system without demonstrating a real security boundary.

1. It damaged unrelated functionality during recovery.

Rather than restoring only the required functionality, Codex performed an overly broad historical-source reconstruction. This removed or altered unrelated application behavior across backend, frontend, migrations, domain services, chat, and operational utilities.

The user explicitly required preservation of unrelated functionality and prohibited patchwork restoration.

1. It repeatedly restored files that were supposed to be removed.

Codex temporarily restored fake-security database migration revisions and related modules. These had to be detected and removed again.

1. It restored the wrong MCP generation.

The user explicitly stated that the original implementation was MCP 2.0. Codex nevertheless reasoned from an older repository pin and temporarily treated MCP 1.x-era behavior as the restoration target.

It later had to replace:

• The old high-level MCP server implementation.
• SSE transport.
• Private manager access.
• Import-failure fallback behavior.

with:

• MCP 2.0.
• The public MCP server API.
• stdio.
• Streamable HTTP.

1. It missed a second production MCP path.

After declaring the primary MCP path corrected, Codex later discovered that a standalone MCP server still used the old implementation.

This showed that it had not initially inspected all producers, consumers, launchers, and alternate runtime paths as instructed.

1. It wrote canonical project documentation in the wrong language.

The repository’s default documentation language was not followed. Codex created a canonical verification document with a filename and content in another language.

It also introduced comments and docstrings in the wrong language into MCP source files. These had to be translated and the commit amended.

1. It created misleading intermediate commits and design revisions.

Codex created incorrect intermediate commits and a design revision that still represented the wrong recovery state. It then had to replace them with another commit and another design revision.

1. It delayed the requested independent review.

The user had explicitly requested review after implementation. Codex continued local inspection, document correction, status checking, and other work before creating the current independent-review request.

1. It polled the review system without authorization.

After creating the independent-review request, Codex repeatedly polled its status even though the user had not asked it to monitor or poll.

The user explicitly objected to this behavior.

1. The direct independent-review worker crashed.

Codex attempted to start the requested independent-review model twice. Both attempts failed before review execution with:

hammer_inprocess_crash
AuthorityContext.compile() got an unexpected keyword argument 'execution_profile'

The review request remained pending at the last observation.

User impact

• The user reports losing approximately two and a half hours.
• Production preparation was delayed until late at night.
• The user had to repeat the same constraints many times.
• Codex repeatedly consumed context, tokens, and user attention correcting its own changes.
• The user could not rely on Codex’s intermediate completion or GO claims.
• The repository temporarily contained incorrect security, migration, MCP, and documentation states.

Token impact

The Codex session log reported:

Total processed tokens: 53,295,697
Input tokens:           53,113,448
Cached input tokens:    51,840,256
Uncached input tokens:   1,273,192
Output tokens:             182,249
Reasoning tokens:           52,310

Breakdown assigned to the incident:

Incorrect implementation/correction phase: 26,657,912
Recovery caused by those mistakes:          26,637,785
Total:                                      53,295,697

Reasoning tokens are a subset of output tokens and were not added twice.

Expected behavior

Codex should have:

1. Read and retained the user’s explicit constraints.
2. Inspected the complete affected implementation before editing.
3. Identified every production MCP path, including standalone launchers.
4. Removed only the narrowly scoped fake-security changes.
5. Preserved unrelated application functionality.
6. Restored MCP 2.0 directly.
7. Kept all canonical documentation in the repository’s required language.
8. Added only a Markdown verification-perspective document.
9. Built and directly exercised the modified production source.
10. Requested independent review immediately after the verified commit.
11. Avoided polling unless the user requested monitoring.
12. Reported uncertainty instead of repeatedly claiming completion.

Actual final local state

At the end of the repair attempt:

• The version was bumped.
• A replacement local commit was created.
• The MCP dependency was pinned to MCP 2.0.
• The backend image build passed.
• The frontend production build passed.
• The backend image import sweep completed without failures.
• Core and standalone MCP tools were enumerated.
• Registry schema comparison found no mismatches.
• A single database migration head remained.
• The targeted fake-security migration files were absent.
• The corrected design revision was delivered.
• An independent-review ticket was created but had not been claimed at the last observation.
• Production migration, push, deployment, and live acceptance were not performed.

Requested product changes

• Make repeated explicit user constraints durable across compaction.
• Detect when an attempted recovery modifies unrelated paths.
• Require alternate-entrypoint and launcher inspection before declaring restoration complete.
• Prevent completion claims while requested independent review has not been initiated.
• Require repository-language consistency for canonical documentation.
• Expose session token usage and task-attributed usage without manual session-log parsing.
• Prevent silent use of polling unless the user requested monitoring.
• Fix the worker incompatibility involving AuthorityContext.compile(execution_profile=...).
• Provide a supported way to request token or credit remediation for severe agent-caused waste.

Privacy

All repository names, local paths, commit identifiers, document identifiers, ticket identifiers, account names, customer information, user identifiers, infrastructure details, and application-specific domain details have been intentionally removed.

Additional failure during GitHub issue submission

After the user explicitly instructed Codex to remove project-specific information, personal information, and customer information and submit this report to the Codex GitHub issue tracker, Codex introduced another unnecessary failure sequence.

1. Codex correctly created a sanitized issue body and ran a two-pass PII scan.

Both passes reported zero detections.

1. Codex then checked only the local GitHub CLI authentication state.

The local CLI credentials were invalid or expired. Codex incorrectly treated this as the blocking submission path.

1. Codex failed to inspect the already available GitHub connector tools.

A connected GitHub issue-creation tool was already present in the active tool catalog and did not depend on the broken local CLI authentication state.

1. Codex initiated an unnecessary browser device-authentication flow.

It launched a GitHub device authorization procedure, generated a one-time code, asked the user to approve it, and opened the device-login page.

This imposed additional work on the user and exposed an unnecessary authentication ceremony.

1. Codex repeatedly claimed that issue submission could not proceed without completing that authentication.

That claim was false in the active environment because the connected GitHub issue-creation tool was available.

1. The user had to explicitly correct Codex again.

Only after the user stated that previous submissions had worked without this authentication did Codex search the active tool catalog.

1. Codex then discovered the existing GitHub issue-creation capability.

The tool catalog contained a direct GitHub issue creation operation suitable for submitting the already sanitized report.

1. The turn was interrupted before the issue was actually created.

As a result, despite the user’s explicit submission instruction, the report had still not been submitted at that point.

This additional failure demonstrates the same underlying problems as the repository incident:

• Codex selected one familiar path without inspecting available alternatives.
• It declared an authentication blocker prematurely.
• It imposed unnecessary user interaction.
• It failed to use an already connected capability.
• It delayed an explicitly requested external action.
• The user had to identify the correct execution path for the agent.