Codex bypasses an explicitly identified working command and invents incompatible API calls

What issue are you seeing?

When a user identifies a known-good local command/provider implementation and explicitly tells Codex to reuse it, Codex may continue searching for or inventing a Codex-specific API path instead of copying the working entry.

In this Windows workspace, multiple local coding tools already used the same OpenAI-compatible LiteLLM gateway successfully. The user pointed Codex to the exact working QwenCode provider pattern and later to the shared gateway_call.py entry. Codex nevertheless:

• created or selected alternate dispatch/call paths;
• supplied unsupported model parameters (one target rejected an explicit temperature with HTTP 400);
• treated a timeout as a reason to redesign the route;
• read only message.content and discarded a valid reasoning_content response;
• kept looking for a "Codex-specific" protocol after the user had explicitly said none was needed.

This is not a request for Codex to know every private script. The failure is that, after the user names a verified executable entry and says "copy this exact working path," the agent still substitutes an unverified neighboring design.

Reproduction shape

1. Have an existing local script or CLI command that successfully reaches an OpenAI-compatible endpoint.
2. Tell Codex the exact path/command and ask it to use or copy that implementation.
3. Also state that it must not create a product-specific protocol.
4. Ask Codex to invoke one target model through that path.
5. Observe Codex inspect unrelated configurations or build a different request path with incompatible parameters instead of first running the supplied command unchanged.

Expected behavior

• Treat the user-supplied known-good command as the first executable hypothesis.
• Run one unchanged minimal invocation before designing a replacement.
• If it fails, report the exact command, exit status, HTTP error, and first divergent boundary.
• Do not invent product-specific APIs or silently change parameters after an explicit "reuse this entry" instruction.

Actual behavior

The agent repeatedly chose novel API/client routes over the known-good local entry. This converted a simple reuse task into repeated diagnosis and false failures.

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 symptom occurred inside the same August 1-2 recovery incident documented in #34477 and #36555.

Local rollout reconstruction now provides exact cumulative counts, replacing the earlier rough ">500M" estimate:

• Initial ARCH task family: 11 sessions, 420,775,426 tokens
• Reopened ARCH task family: 5 sessions, 61,684,846 tokens
• Harness/recovery task families: 76,001,530 tokens
• Original incident total: 558,461,802 tokens
• A later failed ARCH-F1 reattempt: 25,544,534 tokens
• Cumulative affected/recovery total: 584,006,336 tokens
• User-visible quota impact during the original incident: approximately 80% of the weekly allowance (about 60% in the first run and another 20% after reopening)

These totals come from the final payload.info.total_token_usage.total_tokens value in each local rollout, grouped by root thread and child parent_thread_id. Private project transcripts are not attached.