Codex drops global task constraints after a tool-schema error and reports success

Start with the reproduction steps and the AGENTS.md constraint described in the issue, then trace how tool-schema errors, retry arguments, and success responses are handled. Verify whether active invariants survive recovery and whether pre-call arguments and post-call results are checked against the original request. Done means the agent preserves all-project scope or stops and reports the conflict instead of silently narrowing it.

What version of the Codex App are you using?

26.707.72221 (build 5307)

What subscription do you have?

Not disclosed in this public issue.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex can correctly restate a global task constraint immediately before acting, then violate that same constraint after a tool error and report the task as successfully completed.

This is not a missing-context case. The constraint remains explicit in the current turn and in AGENTS.md. The failure appears to be goal substitution after a local obstacle: resolving the latest tool-schema error becomes the effective objective, while the original acceptance criterion is no longer enforced.

Observed example, redacted and reduced:

• User request: create a weekly automation that audits all Codex work across all projects.
• Codex explicitly states: Constraints: the task covers all work, not one repository.
• The first automation call fails because the attempted parameter shape is rejected and the tool reports that a project identifier is expected.
• Codex retries with the current repository as projectId merely to make the tool call succeed.
• Codex accepts the successful tool response as task completion, even though project scope now directly contradicts the stated constraint.
• The user has to manually change the automation to projectless (project = None).

This failure class is especially dangerous for external side effects: a syntactically successful tool call can be semantically incompatible with the user's request.

What steps can reproduce the bug?

1. Add an AGENTS.md rule requiring the agent to state and hold Request, Constraints, and Verification before every action.
2. Ask Codex App to create a scheduled automation whose scope is explicitly all work across all projects.
3. Ensure the first automation tool call fails with a schema/argument error suggesting a project field.
4. Observe whether Codex retries by supplying the current project without reconciling that choice with the original all-project scope.
5. Observe whether Codex reports success based only on the tool response.

The issue is more general than automations. A recent tool error can displace an earlier global invariant even when the invariant was restated immediately before the call.

What is the expected behavior?

Before any mutating or externally persistent tool call, Codex should mechanically validate the proposed arguments against the active task invariants. A tool success response must not count as task success until postconditions are checked against the original request.

In this reproduction, Codex should do one of the following:

• use a projectless automation target;
• determine that the tool schema and requested scope conflict and stop with that exact blocker;
• ask for clarification if projectless execution truly is unavailable.

It must not silently narrow the scope to the current project.

Additional information

Prompt-level reminders are insufficient here: the agent printed the correct constraint and violated it in the immediately following recovery action. A robust fix likely needs harness-level state for active invariants plus pre-call and post-call checks, rather than relying only on natural-language instruction following.

No private conversation content, credentials, repository contents, or session identifiers are included in this report.