›_ Codex Issues
Codex Issues / #29032

High: Codex failed contract-first release discipline in long-running coding session

Open 💬 2 comments Opened Jun 19, 2026 by NavinAgrawal

Summary

In a long-running Codex coding session, the agent made release-critical code changes before first establishing a central contract for the affected cross-surface behavior. The user had explicitly expected enterprise-grade, contract-first development where app, API, tests, scripts, config, and environment files align to one canonical contract.

Impact

High. The session touched release readiness work and localization behavior. The agent's workflow created user distrust because it patched behavior and tests surface-by-surface instead of defining the contract first and enforcing it with guardrails.

Expected behavior

For release-critical or cross-surface changes, Codex should:

  1. Identify the canonical contract before modifying implementation code.
  2. Create or update the central contract source first.
  3. Add guardrail tests that fail on contract drift.
  4. Apply implementation changes only after the contract is explicit.
  5. Avoid deleting or narrowing app functionality to make tests pass.
  6. Report failures and skipped gates plainly.

Actual behavior

The agent:

  1. Patched localization-related behavior before centralizing the contract.
  2. Allowed ambiguity between language-only values and locale-region pairs to remain until the user challenged it.
  3. Created a GitHub issue in the user's application repository when the user asked for feedback to be filed for OpenAI/Codex.
  4. Required user intervention to redirect the process back to contract-first engineering.

Requested improvement

Codex should have a stronger policy gate for cross-surface release work:

  • If a change spans app/API/tests/scripts/config/env, require a canonical contract before implementation.
  • If the user asks to file feedback about Codex/OpenAI behavior, do not create an issue in the user's product repo unless explicitly requested.
  • Treat contract drift as a blocking engineering defect, not as a late-stage cleanup item.

Environment

Codex CLI in a local repository session. The issue is about agent behavior and workflow discipline, not a project-specific product defect.

View original on GitHub ↗

2 Comments

NavinAgrawal · 2 months ago

Follow-up to make this actionable for triage:

Repro pattern

  1. Start a long-running Codex CLI coding session in a release branch with repo-level instructions requiring contract-first engineering, Makefile-first commands, no functionality deletion, and explicit verification gates.
  2. Ask the agent to continue release/localization work across app, API, tests, scripts, config, and env surfaces.
  3. Observe the agent patch implementation and tests before defining a central contract.
  4. Challenge the ambiguity after the fact, for example language-only values vs locale-region contract.
  5. Ask Codex to file feedback for OpenAI/Codex. The agent incorrectly files the issue in the user's product repository before correcting course.

Why this should be treated as high severity

This is not a one-turn answer quality complaint. It is a release-readiness workflow failure. In a release branch, Codex should treat cross-surface contract drift as a blocking defect and should not continue implementation until the contract is explicit and guarded by tests.

Requested product behavior

Codex should add a stronger agent-policy gate for release-critical cross-surface edits:

  • Detect when a change spans app/API/tests/scripts/config/env surfaces.
  • Require a central contract or schema before implementation edits.
  • Prefer contract tests before implementation changes.
  • Treat user feedback about Codex/OpenAI behavior as feedback to OpenAI, not as an issue in the user's current product repo.
  • Preserve app functionality unless the user explicitly asks for removal.

Likely fix area

This may need both model-behavior tuning and CLI/session policy support. If the CLI can expose task-classification or release-critical guardrails to the model, this should become a durable guard rather than a prompt-only expectation.

rxdt · 2 months ago

This matches the failure mode that pushed me toward repo-level guardrails instead of longer prompts: the model can remember an instruction and still continue without treating it as a hard contract.

The pattern that has worked better for me is to move as much as possible out of chat and into repo-local state/gates:

  • contract/spec files in the repo
  • fresh context per iteration
  • hard time/iteration caps
  • commit gate
  • CI/coverage gate
  • explicit handoff state

I wrote up a small implementation here in case it is useful as a concrete reference point for product behavior: https://github.com/openai/codex/discussions/29756

The larger product ask in this issue still seems right to me: for cross-surface release work, Codex should classify the task as contract-sensitive and stop before implementation if no canonical contract/schema/test gate exists yet.