Regression in 0.130.0-alpha.5: Codex no longer follows learned project instructions and workflow conventions

[teseo]

Summary

I am seeing a recent regression where Codex appears to preserve enough local context to continue coding, but no longer reliably respects project-specific operational conventions when performing public workflow actions such as branch naming, PR descriptions, and issue creation.

This report is intentionally sanitized: no private repository names, company names, ticket IDs, usernames, paths, screenshots, or logs are included.

Environment

• Codex Desktop
• Codex CLI/runtime observed in affected sessions: 0.130.0-alpha.5
• macOS local development environment
• Repository had project instructions loaded via the normal project-doc / instructions mechanism
• GitHub and issue tracker workflows were being performed through Codex tools/CLI

Expected behavior

When project instructions and repeated prior workflow conventions exist, Codex should treat them as operational constraints, especially before mutating public surfaces.

Examples of expected behavior:

• Treat branch names as public workflow identity when project instructions prohibit exposing runtime identity on public project surfaces.
• Do not apply a generic default branch prefix if it conflicts with local project conventions or public-identity constraints.
• In PR context, interpret recurring phrases such as "video placeholders" according to the established project workflow, or ask a short clarifying question before editing code.
• Before public mutations such as opening/editing PRs, creating issues, or renaming pushed branches, pause or preview when the action could leave public traces.
• Prefer asking for clarification over making irreversible or noisy public changes when local context is ambiguous.

Actual behavior observed

In recent sessions, Codex appeared to act more mechanically and less contextually than in prior sessions:

• It followed a generic branch prefix convention even though the project instructions required neutral public identity on shared project surfaces.
• It interpreted a PR-description workflow phrase as a request to add UI/code placeholders, creating commits that then had to be removed from history.
• It made or attempted public workflow changes before fully resolving whether the action belonged in code, PR description, or issue tracker metadata.
• It corrected mistakes after user intervention, but only after public noise had already been created.

The coding work itself could still be technically reasonable; the regression is specifically around operational judgment and public/private boundary handling.

Why this matters

For teams using Codex in real repositories, these conventions are not cosmetic. Branch names, PR bodies, issue text, and public workflow artifacts communicate process, ownership, and professionalism. A regression here forces users to over-specify every routine convention that Codex previously inferred correctly.

Possible causes / hypotheses

I cannot prove causality, but the affected sessions were on 0.130.0-alpha.5. Prior sessions on earlier runtime versions appeared to handle the same workflow conventions more reliably.

This may be related to:

• project instructions being present but not promoted strongly enough into action selection,
• compaction or long-context behavior preserving task state but weakening softer workflow conventions,
• generic defaults overriding project-specific public-surface rules,
• insufficient clarification before public mutations.

Thanks.

[etraut-openai]

Thanks for reporting, but we'll need more information and evidence to justify investigating this.

A few questions:

1. Are you able to verify that if you revert to a previous version (e.g. 0.129.0) that the problem goes away?
2. Are you able to repro this with the latest release version (0.130.0)?

If you're able to repro, please use /feedback to upload the session details and post the session ID here.

[teseo]

Correction: I originally framed this around the CLI/runtime version, but that was not precise. The affected product/session was Codex Desktop on macOS, not a standalone invocation of the codex CLI.

I checked the current Desktop DMG (https://persistent.oaistatic.com/codex-app-prod/Codex.dmg) and the app bundle reports CFBundleShortVersionString 26.506.31421 and CFBundleVersion 2620.

So I cannot accurately answer the 0.129.0/0.130.0 rollback question as a CLI regression unless there is a documented mapping from this Desktop build to those CLI/runtime versions. Please triage this as a Codex Desktop issue, or let me know how to map Desktop app builds to the internal CLI/runtime version used by the app.

I have not reproduced the behavior by running the standalone CLI directly.

[etraut-openai]

Closing because there's not enough information for us to investigate. If you can provide additional details or answers to my above questions, we can consider reopening.