Windows Codex App 26.409.7971.0 regression: project .codex/config.toml developer_instructions no longer override ~/.codex/config.toml

[dawnli]

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?

1. In ~/.codex/config.toml, set an unmistakable global instruction, for example:

developer_instructions = """
Reply with exactly: GLOBAL
"""

2. In a trusted project, create ./.codex/config.toml with a conflicting project-local instruction, for example:

developer_instructions = """
Reply with exactly: PROJECT
"""

3. Confirm the project is trusted.
4. From that project root, compare behavior between Codex CLI and Codex App.
5. Start a fresh thread in Codex App for that project.
6. 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:

• Codex App: developer_instructions (config.toml) are not attached to threads initiated within the App #11004 - Codex App: developer_instructions from config were not attached to app-created threads
• Codex Desktop ignores project .codex/config.toml MCP server (Serena) and only loads ~/.codex/config.toml #13025 - Desktop ignored project .codex/config.toml and only loaded ~/.codex/config.toml for MCP config
• Codex Desktop App / codex app-server does not honor project-scoped OTel config in trusted projects #17110 - Desktop did not honor project-scoped .codex/config.toml OTel config
• Codex App is misreporting the state of /fast mode #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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop App / codex app-server does not honor project-scoped OTel config in trusted projects #17110

Powered by Codex Action

[etraut-openai]

I'm not able to repro this. I also looked at the code paths that control this behavior, and I don't (or rather, Codex doesn't) see any recent behavioral changes. Can you double check the behavior you're seeing?