Windows Codex App 26.409.7971.0 regression: project .codex/config.toml developer_instructions no longer override ~/.codex/config.toml
What version of the Codex App are you using (From “About Codex” dialog)?
Windows Store package on this machine:
OpenAI.Codex_26.409.7971.0_x64__2p2nqsd0c76g0- version:
26.409.7971.0
What subscription do you have?
Not material to the repro.
What platform is your computer?
Microsoft Windows 11 Pro 10.0.26100 x64.
What issue are you seeing?
This appears to be a regression introduced by the Windows desktop update that rolled out on April 16, 2026.
In Codex App on Windows, project-scoped developer_instructions from ./.codex/config.toml no longer override the user-level ~/.codex/config.toml developer_instructions.
This is severe because instruction layering is a core workflow and safety boundary. If repo-local developer_instructions lose precedence, the desktop app can silently apply the wrong developer policy for a repository.
The expected layered behavior is:
- user-global defaults come from
~/.codex/config.toml - project-local overrides come from
./.codex/config.toml - for the same key, the project-local value should win in that repository
In the current Windows Codex App build, the effective behavior appears to be the opposite for developer_instructions: the user-level value continues to dominate.
What steps can reproduce the bug?
- In
~/.codex/config.toml, set an unmistakable global instruction, for example:
developer_instructions = """
Reply with exactly: GLOBAL
"""
- In a trusted project, create
./.codex/config.tomlwith a conflicting project-local instruction, for example:
developer_instructions = """
Reply with exactly: PROJECT
"""
- Confirm the project is trusted.
- From that project root, compare behavior between Codex CLI and Codex App.
- Start a fresh thread in Codex App for that project.
- Ask a trivial prompt that makes the winning instruction obvious.
What is the expected behavior?
For a trusted project, the project-local ./.codex/config.toml developer_instructions should override the user-level ~/.codex/config.toml developer_instructions, matching layered config expectations.
In the example above, the effective instruction in that project should be PROJECT, not GLOBAL.
Actual behavior
On Windows Codex App 26.409.7971.0, the session behaves as if the user-level ~/.codex/config.toml developer_instructions still wins, even in a trusted project with its own ./.codex/config.toml override.
Additional information
This looks related to the broader history of Desktop/App config-layer drift, but it is not the same symptom as older reports.
Related issues:
- #11004 - Codex App:
developer_instructionsfrom config were not attached to app-created threads - #13025 - Desktop ignored project
.codex/config.tomland only loaded~/.codex/config.tomlfor MCP config - #17110 - Desktop did not honor project-scoped
.codex/config.tomlOTel config - #14689 - Codex App / CLI config drift around
config.toml
Why this one is especially severe:
- it affects
developer_instructions, not just MCP or telemetry config - it can invert repository-specific workflow/safety policy
- it is easy to miss because the app still starts and works, but with the wrong instruction layer winning
Current workarounds are not acceptable as a real fix:
- duplicating project rules into
~/.codex/config.toml - moving the most critical rules into
AGENTS.md - abandoning the desktop app for CLI in repos that depend on strict project-local instruction overrides
Please treat this as a regression in Desktop/App config precedence on Windows.
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗