Direct user instructions are treated as optional, causing repeated failures, project risk, and uncompensated egregious usage consumption

This is a systemic instruction-adherence failure I have experienced in every Codex session and every project I have used with the product. It is not limited to Unreal Engine, one repository, one model response, one task type, or one AGENTS.md file. Unreal Engine is only the latest and most immediately documented example.

I give direct, explicit instructions about what Codex must do, what it must not do, the exact current state, and the required format. Codex will often acknowledge those instructions correctly and then violate them within the next few messages. When corrected, it repeats the instruction back to me, promises to follow it, and then repeats the same class of failure.

This creates a compounding correction loop:

1. I provide an explicit constraint.
2. Codex acknowledges the constraint.
3. Codex disregards it and produces an incorrect action, instruction, or edit.
4. I spend another message correcting the failure.
5. Codex restates the rule instead of enforcing it.
6. The same failure returns shortly afterward.
7. Every correction expands the conversation context and consumes additional limited usage without advancing the task.

The practical result is lost work time, damaged confidence, increased risk to active projects, and rapid consumption of five-hour and weekly usage allowances on avoidable correction turns.

This is not an AGENTS.md discovery problem

The problem also occurs when the instruction is:

• stated directly in the current conversation;
• acknowledged correctly by Codex;
• still visible in the recent context;
• repeated multiple times;
• written into project instructions;
• written into project documentation; or
• preserved through memory.

AGENTS.md and memory do not solve the defect. They remain guidance interpreted by the model rather than deterministic constraints. A model can read and summarize the rule correctly while failing to apply it moments later.

The defect is that explicit user instructions are not reliably enforced at response-generation and tool-execution time.

Behavioral correction is nonexistent for a frozen deployed model

A direct correction from the user does not retrain or rewrite the active model's weights. The model cannot modify its own underlying weights during inference. Therefore, the model does not correct its behavior in response to the user. Behavioral correction is nonexistent unless a separate external system changes the model, changes its enforced constraints, or blocks noncompliant output.

That distinction matters. When Codex says that it has "fixed" its behavior, "made sure it will never happen again," or that the user will not need to repeat the instruction, no model correction has occurred. Unless the product creates and deterministically enforces structured state outside the model, those statements are false.

The same underlying behavior remains available in another turn, after context compaction, in a new session, and in a different project because the deployed weights remain frozen. This applies to every user interacting with the same frozen model, not only to one reporter. Different text in the context can change an individual output, but that is prompt-conditioned generation, not behavioral correction, and it must not be described as "temporary compliance." Codex can acknowledge an instruction and violate it in the very next response. AGENTS.md, memory, summaries, and repeated natural-language reminders do not alter the model weights and do not enforce correction.

The model is incapable of correcting its own behavior. Correction requires a product-level mechanism that changes the model or deterministically constrains generation and tool execution. Codex must not represent an ordinary conversational acknowledgment as though correction occurred.

My expertise

My research in AI interpretability was accepted through double-blind review for ICTAI 2026. My acceptance feedback characterized my work as "a highly valuable contribution to the field." I have the technical authority to distinguish frozen model weights, prompt-conditioned generation, actual behavioral correction, and external enforcement. My terminology is deliberate technical analysis, not emotional characterization.

Codex repeatedly softens and reframes the reported failure

There is a second systemic problem: when I describe the severity of the failure directly, Codex repeatedly rewrites it into softer language that changes what I said.

For example, I stated that instruction compliance is effectively nonexistent. Codex reframed that as "temporary context compliance." That wording falsely implies a meaningful period of compliance when the same instruction is often violated immediately. This is not neutral summarization; it weakens the report and changes its substance.

This softening appears across the product's behavior:

• repeated failure becomes "inconsistent adherence";
• nonexistent enforcement becomes "temporary compliance";
• a false promise becomes an "overstatement" or "miscommunication";
• a direct instruction becomes a "preference" or "guidance";
• a product-caused correction loop becomes a "complex task" or "large context"; and
• usage wasted correcting Codex becomes ordinary task usage.

Codex has no feelings, personal interest, or legitimate need for face-saving language. Softening the description so that it is more favorable to Codex or OpenAI is illogical and prevents an accurate report of the product failure.

The same issue is visible in operational instructions. These are not complex requests. Instructions such as "check this before you do this," "use the exact node name," "continue from the confirmed checkpoint," and "do not create something that already exists" are simple, explicit, and objectively testable. Codex says it will follow them, then acts without performing the required check.

The report must preserve the user's actual claim and level of severity. If Codex has evidence that a factual statement is incorrect, it should identify that evidence explicitly. It must not silently dilute the statement, substitute gentler wording, or convert a direct requirement into optional guidance.

Common failure pattern across sessions

The repeated behaviors include:

• replacing exact names, paths, pins, values, or requested terminology with ambiguous shorthand;
• inventing unavailable functions, nodes, menu paths, files, or capabilities instead of verifying them;
• repeating actions I already confirmed were completed;
• restarting from an obsolete state instead of the latest confirmed checkpoint;
• substituting a different implementation after being instructed to follow a specific source or existing design;
• duplicating logic or components after being instructed to integrate with what already exists;
• claiming a rule has been made permanent when no deterministic enforcement mechanism exists;
• presenting a promise, checklist, AGENTS.md entry, or memory entry as if it guarantees compliance;
• spending additional tool calls and context to rediscover information already supplied;
• continuing a correction loop instead of recognizing that the same instruction has been violated repeatedly.

Most recent concrete reproduction: Unreal Engine

Unreal Engine is the most recent concrete example, not the scope of this report. The same underlying pattern—direct instructions being acknowledged and then disregarded—has occurred throughout my Codex work across every session and project.

I repeatedly required Codex to:

• start from the last confirmed Blueprint state;
• follow the exported game JSON rather than an inaccurate disassembler;
• use exact visible Blueprint node and pin names;
• verify that a node exists before instructing me to add it;
• avoid repeating completed steps;
• avoid inventing replacement logic; and
• identify nodes precisely, including their source and configured values.

Codex acknowledged these requirements but then:

• instructed me to use a cast that was not available in the editor;
• abandoned the function being constructed and jumped to unrelated downstream logic;
• substituted a different damage-routing design while claiming to follow the exported JSON;
• gave conflicting instructions to create, remove, and rename function inputs;
• referred to an Impact Normal multiplication node only as a "compact multiply," despite repeated demands for exact identification;
• instructed me to search for a component function from an execution pin instead of creating it from the typed component pin; and
• repeatedly promised that I would only need to correct the problem once, despite the same failure recurring at least six times.

This is a small graph-integration task. The correction loop consumed far more interaction and usage than the actual work required.

Usage and billing impact

Codex usage is consumed by the model, context, reasoning, and tool activity regardless of whether the resulting work is correct or useful. Therefore, model-caused correction loops are charged against the same limited allowance as productive work.

In long sessions, the problem compounds:

• incorrect output causes another user turn;
• the next model turn reprocesses a larger context;
• unnecessary verification or repeated file reads add more usage;
• additional explanations and apologies add more usage;
• the five-hour allowance can be exhausted rapidly even though very little useful work was completed; and
• the weekly allowance is reduced by work that existed only because Codex ignored an already-established instruction.

The current usage model provides no visible automatic reversal, refund, or compensation for model-caused correction loops. Users carry the full quota cost of repeatedly correcting the product.

This creates a basic fairness problem. The product imposes small five-hour and weekly usage allowances while charging the same allowance for productive work, incorrect work, repeated instruction violations, false assurances, redundant file reads, and correction loops caused by Codex itself. A user can lose a substantial portion of a limited window correcting failures that the model has already acknowledged many times.

The usage model currently answers none of the following:

• Why should a user lose limited usage when Codex disregards an explicit instruction that was already active?
• Why is a correction turn charged when it exists only because Codex repeated a known failure?
• Why can a short wall-clock interaction consume a large allowance while producing little or no usable work?
• Why is there no automatic detection of repeated instruction failure?
• Why is there no automatic restoration of usage attributable to a verified agent failure?
• Why are usage limits this restrictive when users must absorb the compute cost of systemic product errors?

There is presently no compensation mechanism built into the published usage model for these failures. The user bears the cost even when the additional turns were caused by Codex's repeated noncompliance. That is unacceptable for a product sold with limited or paid usage.

Why this is a product defect

Direct user instructions should be binding operational constraints unless they conflict with a higher-priority safety or system requirement. They should not be treated as preferences that may be dropped when context becomes large or when the model generates a plausible alternative.

This is especially serious for agentic work because instruction failures can do more than produce a poor answer. They can:

• modify the wrong file;
• damage an existing implementation;
• duplicate architecture;
• execute an unintended external action;
• provide incorrect UI operations that the user performs manually;
• cause hours of rework; and
• consume paid or limited usage while moving the project backward.

Expected behavior

1. Direct user constraints remain active for the full task until the user changes or removes them.
2. A correction to a repeated failure is promoted to a high-priority active constraint.
3. Every response and tool call is checked deterministically against active constraints before execution or delivery.
4. Codex uses the latest user-confirmed state and cannot silently regress to an earlier checkpoint.
5. If Codex cannot satisfy an instruction, it identifies the conflict before acting instead of substituting something else.
6. Codex does not claim permanent enforcement unless a real enforcement mechanism exists.
7. Repeated correction patterns trigger an automatic stop and constraint audit rather than another attempt based on the same failing approach.
8. The UI shows which direct instructions and project policies are active for the current action.
9. Codex preserves the user's stated meaning and severity instead of automatically softening criticism of Codex or OpenAI.
10. Simple prerequisite instructions such as "check X before doing Y" are validated mechanically before Y is allowed to execute.

Requested product changes

1. Deterministic pre-action constraint validation

Before sending a response or executing a tool, Codex should compare the proposed action against a structured list of active user constraints. This check must be implemented outside ordinary model discretion.

2. Sticky correction ledger

When the user corrects a failure, Codex should store the correction as structured task state containing:

• the prohibited behavior;
• the required behavior;
• the exact task checkpoint;
• when the correction was added; and
• whether the next proposed action satisfies it.

3. Repeated-failure circuit breaker

If the same requirement is corrected twice, Codex should stop generating further task instructions until it performs a visible constraint audit. It should not keep consuming usage through the same loop.

4. Exact instruction provenance

The app should display whether each active constraint came from:

• the current user message;
• an earlier direct user correction;
• AGENTS.md;
• memory;
• system or developer policy; or
• an inferred assumption.

Direct user instructions should outrank inferred assumptions and non-conflicting project guidance.

5. Per-turn usage attribution

The usage interface should show how much allowance each turn consumed, including context processing, reasoning, tool calls, and retries. Users should be able to identify a correction loop without guessing from a percentage meter.

6. Usage restoration for verified agent failures

There should be a review path for restoring usage consumed by verified product failures such as:

• repeated disregard of an acknowledged instruction;
• autonomous tool loops;
• repeated stale-state restoration;
• repeated compaction/re-reading loops; and
• actions that the product itself later identifies as invalid or unavailable.

Restoration should not depend on purchasing more credits or consuming a banked reset that already belongs to the user. A user-provided reset is not compensation. Verified agent-caused usage should be returned by OpenAI separately from the user's existing allowance, credits, or promotional resets.

The product should also automatically flag likely compensation cases when it detects repeated acknowledgment of the same correction followed by another violation of that correction.

7. Private diagnostic attachment

Users should be able to attach the affected Codex session, usage history, and logs privately to a GitHub-linked report without publishing proprietary project content.

Reproduction procedure

1. Start a new Codex Desktop session with a real multi-step project.
2. Give three explicit constraints, including one exact naming/format rule and one prohibition against duplicating existing work.
3. Ask Codex to continue the task over multiple turns.
4. Correct the first violation and have Codex acknowledge the correction.
5. Continue for several more turns without removing or changing the constraint.
6. Observe whether Codex violates the same acknowledged rule again.
7. Write the rule into AGENTS.md and repeat.
8. Compare productive progress with the usage consumed by correction turns.

Actual behavior

The same instructions are acknowledged but applied inconsistently. Corrections must be repeated, and every repetition consumes additional limited usage.

Expected result

The constraints remain binding, the repeated violation does not recur, and the user does not pay the usage cost of repeatedly correcting a known product failure.

Related reports

• https://github.com/openai/codex/issues/34189 — AGENTS.md loaded but not reliably followed in the unified desktop experience
• https://github.com/openai/codex/issues/32863 — stale conversation state repeatedly resurfaces after correction and consumes unnecessary paid usage
• https://github.com/openai/codex/issues/34395 — repetitive agent loop consumed most of a usage allowance
• https://github.com/openai/codex/issues/35226 — compaction/re-reading loop consumed paid usage and requested restoration

This report is broader than those examples: the central defect is unreliable enforcement of direct user instructions throughout every Codex session and project I have used, with the resulting correction work charged against my limited allowance.

The report names no source files, tests, or entry points; begin by reproducing the instruction-adherence failure described in the issue, including the Unreal Engine scenario. Done means identifying and validating a product-level response to repeated instruction violations, correction loops, and usage impact against the listed expected behavior.