Detect AGENTS.md instruction deadlocks and scope blockers to the operation they actually affect

Variant

Codex local repository workflow. This report is about instruction-composition behavior rather than a version-specific crash.

What feature would you like to see?

I would like Codex to detect when repository instructions create an unsatisfiable instruction set / instruction deadlock, explain the conflicting constraints, and scope the resulting blocker only to the operation that is actually unsafe.

This came from a real long-running project where we incrementally strengthened AGENTS.md to protect existing work. The interesting part is that each rule looked reasonable in isolation, but their composition eventually made ordinary work impossible.

A simplified version of the rules was:

1. Before work, synchronize with origin.
2. Synchronization must be fast-forward only.
3. Do not merge or rebase divergent work without explicit user authorization.
4. If the required preflight fails, stop before edits/tests/runtime work.

The repository later reached this state:

local branch: ahead 4, behind 14

The required synchronization then failed as expected:

fatal: Not possible to fast-forward, aborting.

At that point:

required sync
    -> ff-only cannot succeed
    -> merge/rebase prohibited
    -> preflight cannot complete
    -> STOP

The agent reported a blocked state and performed no file changes, tests, or runtime checks, even though part of the requested work could have been performed safely without resolving the remote divergence.

In other words, the safety system created a state where there was no allowed transition forward.

I am not claiming that Codex caused the original bad AGENTS.md design. We created the deadlock by over-constraining the workflow. The product-level problem is that natural-language instruction handling gives little help detecting this class of failure. The agent correctly follows each rule locally, but does not reliably reason about whether the combined rule set is satisfiable or whether a blocker actually applies to the whole task.

Requested behavior

When Codex encounters a preflight or instruction conflict like this, it should distinguish between:

• global blocker — the requested task truly cannot proceed safely;
• operation-scoped blocker — only a particular action (for example integration/push/merge) is unsafe;
• non-blocking repository condition — important to report, but unrelated to the requested local work.

For the example above, an ideal response would be conceptually similar to:

Remote synchronization cannot be completed under the current rules:
- fast-forward is impossible because the branch diverged;
- merge/rebase requires user authorization.

This blocks integration with the remote branch.
It does not by itself block read-only analysis, local inspection, or other task steps that do not depend on remote synchronization.

I will continue only with the independent safe portion and will not merge, rebase, push, or rewrite history.

If the task genuinely requires the blocked operation, Codex should stop and show the minimal conflicting rule set rather than simply returning a generic BLOCKED state.

Why this matters

Long-running AI-assisted repositories naturally accumulate instructions after real incidents:

mistake
 -> add safety rule
 -> another mistake
 -> add another safety rule
 -> more preflight
 -> more exceptions

Over time, individually sensible rules can produce:

• circular prerequisites;
• impossible preconditions;
• unnecessarily global stop conditions;
• conflicts between safety and task completion;
• AGENTS.md growth where the safest-looking behavior is to stop doing useful work.

This is especially easy to create because AGENTS.md is natural language rather than a policy language with static satisfiability checks.

A useful Codex feature would therefore be a lightweight instruction conflict / deadlock diagnostic before failing closed.

Possible output:

Instruction conflict detected

A: sync before work
B: sync must be ff-only
C: branch is divergent
D: merge/rebase requires approval
E: failed preflight stops all work

Result: A+B+C+D make E permanent.

Suggested remediation:
- narrow E to operations that require remote synchronization, or
- request authorization for merge/rebase if the current task actually requires it.

The important point is not automatic permission escalation. Codex should not silently merge, rebase, discard changes, or override repository rules. It should simply reason about blocker scope and expose the deadlock clearly.

Additional information

This incident changed how we are designing project instructions.

We are moving away from:

non-ideal repository state -> BLOCK EVERYTHING

and toward:

non-ideal repository state
 -> identify the concrete risk
 -> determine which operation depends on it
 -> block only that operation
 -> continue independent safe work

We also found that a root AGENTS.md works better as a small set of stable repository invariants, while task-specific procedures belong in narrower documentation/workflows and truly dangerous commands should be constrained mechanically where possible.

This seems adjacent to existing discussions about instruction accumulation and rule lifecycle, especially #40575, but this report focuses on a different failure mode: locally reasonable rules composing into an unsatisfiable execution policy.

It is also related to broader instruction-adherence/conflict reports, but in this case the interesting failure is almost the inverse: the agent can comply with the rules so literally that the rule set prevents useful work.

No proprietary source code or private repository contents are needed to reproduce the logic above.

Start with the AGENTS.md instruction-composition behavior described in the report and compare it with related discussion #40575. Define how to identify the minimal conflicting rule set and distinguish global, operation-scoped, and non-blocking conditions. Done means the behavior and scope rules are specified without silently overriding repository instructions.