Codex Desktop on macOS shadows project-local developer_instructions with a host-generated thread override

Yes. This applies not only to repo level config.toml but also the user level one under ~/.codex
Its extremely annoying because neither codex cli nor the new ChatGPT Desktop / Codex app support main agent modes like opencode so the only place to put main agent only instructions is in the developer_instructions field which is overridden in the Desktop app.

I believe #12926 was about the same missing behavior: Codex has no supported way to add developer instructions without replacing instructions from another layer

I have encountered the same problem in other project. It writes generated project rules to .codex/config.toml. If it sets developer_instructions, the user's profile-level instructions are lost because the field is replaced, not composed. Updating AGENTS.md is not an option because it is normally tracked by the project and would leave a working-tree diff.

#33238 shows the same problem at the Desktop boundary: app-provided developerInstructions shadows the project value.

#9424 already demonstrates a possible internal approach: collaboration-mode instructions are added as a separate developer message and coexist with regular developer instructions.

A backward-compatible solution could keep developer_instructions as the replacement field, while adding an explicitly additive field such as additional_developer_instructions or developer_instruction_files. App Server should similarly have a separate additive field for host context.

This is not only a Desktop bug; it is a missing instruction-composition feature.
Please reconsider the request from #12926 in this context

I can confirm that this also affects user-level ~/.codex/config.toml on a newer macOS Desktop build, and I have rollout-level evidence that the shadowing can cause substantial unnecessary model re-entry during asynchronous waits.

Environment

• Codex Desktop: 26.803.41515 (build 6321)
• macOS: 27.0 (26A5388g)
• Model: gpt-5.6-sol
• Primary Desktop rollout metadata: originator = "Codex Desktop", source = "vscode"
• Observed on 2026-08-10/11

User-level configuration

I added a sanitized form of the following to ~/.codex/config.toml and started fresh Desktop tasks:

developer_instructions = """
DESKTOP_WAIT_POLICY_MARKER

For long-running asynchronous work:
- Empty write_stdin polls must use yield_time_ms >= 180000.
- functions.wait must use yield_time_ms >= 180000.
- The outer functions.exec yield must be longer than the longest nested wait.
- Do not use long waits for non-empty interactive write_stdin calls.
- Do not wake the model only to report that work is still running.
"""

The same block appears as an initial developer-role message in child sessions with:

originator = "codex_exec"
source = "exec"

Those child sessions then used functions.wait with yield_time_ms = 180000, showing that the configuration is valid and is applied on that path.

However, the block and marker are absent from the initial developer-role messages of fresh primary Desktop sessions. The Desktop sessions instead contain the host-generated app context and other request-level developer messages.

Measured behavioral impact

In local rollout files created after this configuration was added:

• 68 functions.wait calls occurred.
• 59 used only 10000–30000 ms.
• Six calls used 180000 ms, and all six were in codex_exec sessions that contained the configured developer instructions.
• Primary Desktop sessions also made three empty write_stdin polls: 30000, 30000, and 1000 ms.
• No empty Desktop write_stdin poll used 180000 or 300000 ms.

One representative trace demonstrates the resulting extra model turn:

1. An outer JavaScript functions.exec cell awaited a nested write_stdin(..., yield_time_ms: 30000).
2. The outer cell yielded after approximately 11.2 seconds with Script running with cell ID ..., while the nested process was still running.
3. The model was invoked again and issued functions.wait(..., yield_time_ms: 30000).
4. The original nested operation completed approximately four seconds later.

The unnecessary intermediate model invocation recorded:

input_tokens:        214,725
cached_input_tokens: 214,016
output_tokens:            64
total_tokens:        214,789

This is local rollout telemetry, not a claim about the private subscription billing ledger. It nevertheless shows that losing the configured wait policy can force a full large-context model re-entry merely to continue waiting.

This connects the configuration-shadowing bug to the polling/usage problems reported in #35259 and #13733.

Expected behavior

User-level and project-level developer instructions should be composed additively with Desktop host context. Desktop-generated context must not replace explicitly configured instructions.

Conceptually:

user config developer_instructions
+ project config developer_instructions
+ Desktop host/app context
+ collaboration-mode context

If replacement semantics must remain available for backward compatibility, the Desktop host context should use a separate additive protocol field rather than ConfigOverrides.developer_instructions.

Suggested regression coverage

A Desktop-style thread/start test should provide all of the following:

1. user-level developer_instructions containing a unique marker;
2. project-level developer_instructions containing a second marker;
3. non-empty host-generated Desktop instructions;
4. collaboration-mode developer context.

The resulting initial model request should contain all expected additive blocks exactly once. The test should also verify parity between primary Desktop sessions and codex_exec sessions.

Full rollout files are not attached because they contain private prompts, local paths, repository context, and account metadata. Sanitized event excerpts can be provided if needed.