Codex Desktop developer instruction can override repository orchestration and block explicit visible-task workflows

What version of the Codex App are you using?

ChatGPT Desktop powered by Codex & OWL, version 26.901.22334 (released 3 Sep 2026).

This appears to be a regression introduced by this release: the immediately previous Codex Desktop version installed on the same machine did not exhibit this behavior. The same repository-governed visible-task workflow worked without requiring an additional top-level user message explicitly restating that the slices were separate tasks.

What platform are you using?

Windows 11 x64.

What issue are you seeing?

After updating Codex Desktop to 26.901.22334, a long-running repository-governed workflow that intentionally delegates implementation slices to separate visible Codex tasks began stopping before delegation.

The repository's user-authored orchestration procedure explicitly requires the visible task route (codex_app.create_thread / existing-thread reuse) and explicitly prohibits silently substituting hidden/same-role subagents for those implementation tasks. This distinction is intentional: each implementation slice is separately visible, independently reviewed, separately evidenced, and may be reused later for related slices.

In the affected session, Codex reported that a developer-level session instruction directs subtasks of the current request to the multi-agent/subagent tools and reserves create_thread for explicit requests to create separate tasks. The agent therefore treated the repository procedure and the session instruction as conflicting authorities and stopped implementation dispatch, even though all required codex_app task tools were present and callable.

This was not a tool failure. It was a policy/instruction conflict introduced by the session behavior.

The workflow resumed only after I manually sent an additional message explicitly saying that I wanted the planned implementation slices created and run as separate visible Codex tasks/conversations. After that message, the same agent immediately said the governed separate-task route was permitted and started dispatching the slices through codex_app.create_thread.

So the practical regression is:

• the immediately previous Desktop version allowed this repository-governed workflow to proceed normally;
• after updating to 26.901.22334, repository/user workflow already clearly requires separate visible tasks, but Codex nevertheless classifies the planned work as generic subtasks and blocks the repository-prescribed task route;
• the user must restate the same intent in a new top-level message using the exact “separate tasks” distinction before Codex will proceed.

Steps to reproduce

1. Use Codex Desktop 26.901.22334 with a repository that has explicit user-authored orchestration instructions requiring implementation work to be delegated as separate visible Codex tasks using codex_app.create_thread (or reuse of an existing visible task), and prohibiting substitution with hidden/same-role subagents.
2. Start a supervising task and ask it to execute an implementation plan containing multiple separately reviewable slices.
3. Have the supervising task load and follow the repository orchestration instructions.
4. Observe that the session-level coordination instruction directs the implementation work toward multi-agent/subagent tools instead.
5. The agent identifies an authority conflict and stops before dispatch, despite codex_app.create_thread being available and no tool call having failed.
6. Send a new user message explicitly stating: the slices are requested as separate visible tasks/conversations and create_thread should be used for them.
7. Observe that the agent now says the separate-task route is permitted and proceeds normally.

For comparison, the same governed workflow did not require step 6 on the immediately previous Codex Desktop version installed on this machine.

Expected behavior

A developer-level default for ordinary subtasks should not break an explicit repository/user orchestration model that intentionally requires separate visible tasks.

At least one of these behaviors would avoid the regression:

• Treat an explicit repository/user instruction requiring separate visible tasks as sufficient separate-task intent; do not require the user to restate it in a new message.
• Make the developer instruction a default preference rather than an unconditional routing rule when a more specific user workflow requires a different first-party coordination primitive.
• Provide an explicit task-coordination setting/configuration that lets users choose subagents vs visible separate tasks for supervised workflows.
• If the distinction must be based on direct user text, surface that requirement clearly before execution instead of letting the agent discover an authority conflict mid-workflow.

The important semantic distinction should remain intact: ordinary internal subtasks can use multi-agent/subagent tools, while intentionally separate visible work units should continue to use create_thread when the user/project workflow requires that model.

Impact

This breaks unattended and carefully governed multi-task workflows:

• implementation stops for manual intervention even though all required tools are healthy;
• repository orchestration rules become ineffective against a hidden higher-priority routing instruction;
• users must duplicate orchestration intent in live chat after it has already been defined in repository instructions;
• long-running workflows that were designed to continue autonomously can halt as soon as the first delegated slice is reached.

In my case this interrupted a multi-slice implementation run that was intentionally designed to continue unattended, with independent visible child tasks and independent review/evidence boundaries.

Additional information

The agent correctly distinguished this from tool availability: it reported that all required native task tools were present and that no call had been rejected.

It also correctly avoided quoting the non-public developer instruction verbatim; the description above is a paraphrase of the behavior it reported.

The workaround was simply to send a new direct user message explicitly requesting separate visible tasks. That immediately cleared the conflict without any configuration or tool changes, which strongly suggests the issue is instruction-routing semantics rather than task-tool availability.

Because the immediately previous Desktop version did not show this behavior on the same workflow, this looks like a regression introduced with the 26.901.22334 update rather than a longstanding repository-instruction incompatibility.

Related but not duplicate: #38687 discusses the intended boundary between multi-agent subagents and create_thread-created user-owned tasks. This report is the inverse problem: a legitimate repository-governed visible-task workflow is blocked until the user redundantly restates that the work units are separate tasks.

No source files or tests are named. Start by tracing the session instruction-routing and task-coordination entry points, including multi-agent/subagent handling and codex_app.create_thread. Reproduce the workflow on version 26.901.22334; done means explicit repository/user instructions for separate visible tasks proceed without an additional top-level restatement.