Codex repeatedly substitutes a neighboring tool workflow after explicit user corrections

What issue are you seeing?

Codex may repeatedly replace a simple, explicitly corrected tool/surface request with a neighboring workflow, even after the user states what they do not want.

Observed recovery sequence:

1. The user installed Orca and asked for configuration that would let a primary reviewer coordinate existing local coding tools.
2. Codex redirected the task to standalone PowerShell/terminal CLI installation instructions.
3. The user explicitly corrected that they installed a visual tool because they did not want multiple terminal CLIs fighting each other.
4. Codex still treated Qwen CLI availability as the solution, although the user had explained that QwenCode's provider setup was only a known-good connection example.
5. The user supplied screenshots and exact local configuration directories. Codex continued diagnosing adjacent installation/API questions instead of answering the corrected request.

The problem is not a single wrong guess. It is failure to update the active goal after multiple direct corrections, while continuing to spend tools and tokens on the superseded route.

Reproduction shape

1. Ask Codex to configure product/surface A to control or coordinate existing tool B.
2. Let Codex propose terminal/CLI workflow C.
3. Explicitly say: "Do not use C; I need A with B."
4. Provide local paths or screenshots proving A and B are installed.
5. Observe Codex continue installing, explaining, or debugging C.

Expected behavior

After the first explicit correction:

• replace the active goal with the newest user wording;
• discard commands and assumptions belonging to the superseded route;
• restate the corrected target in one sentence;
• inspect only the files or product capability needed for that target;
• if A cannot control B, state that limitation directly instead of offering C again.

Actual behavior

The agent acknowledged corrections but retained the old tool model and repeatedly returned to terminal CLI installation, Qwen-as-executor assumptions, and API diagnostics. The user had to restate the same simple distinction many times.

Why this warrants a product issue

This failure survived fresh turns, screenshots, exact paths, explicit negative constraints, and direct statements such as "that is not what I asked." It therefore behaved like sticky stale-goal state rather than an ordinary one-off misunderstanding.

Environment

• OpenAI Codex Desktop for Windows: 26.727.6591.0 (x64 MSIX)
• VS Code extension: 26.727.40816
• Codex CLI recorded in rollouts: 0.146.0-alpha.9.2
• Windows: 10.0.26200.8875
• Model observed: GPT-5.6 Sol

Measured incident impact

This behavior appeared during recovery from the same August 1-2 incident documented in #34477 and #36555. The numbers below are shared incident severity, not all attributed exclusively to this one misunderstanding:

• Original ARCH/Hook/Harness failure families: 558,461,802 tokens
• Later failed ARCH-F1 reattempt: 25,544,534 tokens
• Cumulative affected/recovery total: 584,006,336 tokens
• User-visible original quota loss: approximately 80% of the weekly allowance (about 60% + 20%)

The exact total was reconstructed from final rollout total_token_usage.total_tokens records and child parent_thread_id relationships. Private transcripts and project content are not attached.