[Bug/Agent Failure] Model Handoff Loop & MCP Bypass on gpt-5.6-terra

Bug Report: Severe Agent Loop Failure / Silent Model Handoff (gpt-5.6-terra to gpt-5.6-sol)

Context & Environment:

  • Date/Time: July 10, 2026 (Morning Window: 5:08 AM – 8:30 AM Arizona Time)
  • Active Models: gpt-5.6-terra (primary), shifting to gpt-5.6-sol at 8:28 AM.
  • Persisted Configuration: service_tier = "default" (Fast mode disabled, despite global UI State showing announcement seen).
  • Configured MCP Servers: openaiDeveloperDocs, context7, node_repl, pencil, computer-use (via config.toml).

The Problem:
During a highly intensive production run, Codex bypassed the explicitly configured MCP servers entirely, defaulting to local shell/tool executions via the codex_app namespace. This resulted in an incredibly dense, expensive, and unmonitored execution loop consisting of 281 custom tool executions and 69 apply_patch edits over 3.5 hours.

Support has ignored standard tickets regarding this compute drain. The telemetry shows a significant failure in model handoff gating and MCP routing logic during intensive script patching workflows.

Execution Data Breakdown:

  • 5:08-5:20 AM (Claude/AGENTS Migration): 13 tool executions (gpt-5.6-terra, medium)
  • 5:23-5:28 AM (Codex Skill Setup): 17 tool executions (gpt-5.6-terra, medium)
  • 5:46-5:58 AM (Excel Parsing Script): 28 tool executions (gpt-5.6-terra, low)
  • 6:04-7:37 AM (Textbooks Pipeline Build): 154 tool executions (gpt-5.6-terra, low to medium)
  • 7:39-8:30 AM (Handoff Continuation): 69 tool executions (Silent model swap to gpt-5.6-sol at 8:28 AM)

Expected Behavior:
The agent should have utilized the configured node REPL and document MCP servers instead of infinitely looping through recursive local workbook patching and execution checks (processor.mjs).

Requested Action from OpenAI Devs:
Please investigate why gpt-5.6-terra bypassed local config.toml MCP routing flags during active shell execution loops and why the model handoff to sol triggered silently at 8:28 AM without updating thread configuration profiles.

I suspect low reasoning effort may be a key factor. From my experience, the model is more likely to avoid MCP tools and fall back to shell commands or repetitive patching when set to low. Testing the same task with high reasoning effort would help confirm this.