Infinite loop inspecting agent status and missing functions.exec tool with GPT-5.6 model #39004

Activity

1. yeapllg

   added

   bugSomething isn't workingSomething isn't working

   on Aug 17, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   tool-callsIssues related to tool callingIssues related to tool calling

   on Aug 17, 2026
3. github-actions commented on Aug 17, 2026

   

   github-actionsbot

   on Aug 17, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Windows Desktop 0.148-alpha.9: parent /root session has no exec, only wait + collaboration tools #38960
   • [Bug] Agent-status intents are routed to placeholder shell output, causing a tool-selection loop #38132

   Powered by Codex Action
4. jdcodes1 commented on Aug 17, 2026

   

   jdcodes1

   on Aug 17, 2026

   More actions

   Looked at the multi-agent wait machinery on main @ 1f41cc5 — the loop you captured is close to the rational model response to what the tools actually return, which makes this fixable at the tool layer rather than the model layer.

   1. wait tells the model nothing on timeout. The v2 wait handler returns, in total, {"message": "Wait timed out.", "timed_out": true} — no per-agent states, no distinction between "children are working", "children are stuck", and "children died":

   codex/codex-rs/core/src/tools/handlers/multi_agents_v2/wait.rs

   Lines 140 to 156 in 1f41cc5

   	) -> Self {
   	let message = match outcome {
   	WaitOutcome::MailboxActivity => "Wait completed.",
   	WaitOutcome::Steered => "Wait interrupted by new input.",
   	WaitOutcome::TimedOut => "Wait timed out.",
   	};
   	let message = match requested_timeout_ms {
   	Some(requested_timeout_ms) if requested_timeout_ms < timeout_ms => format!(
   	"{message}\n\nRequested timeout of {requested_timeout_ms}ms was clamped to the minimum of {timeout_ms}ms."
   	),
   	Some(_) | None => message.to_string(),
   	};
   	Self {
   	message,
   	timed_out: outcome == WaitOutcome::TimedOut,
   	}
   	}

   (The No agents completed yet line in your transcript is the TUI's rendering of the empty agent-state map — tui/src/multi_agents.rs#L590 — not information the model can act on.) A model whose children never complete gets an endless series of indistinguishable timeouts, so "wait → inspect → wait" repeats forever; there's no terminal state for it to observe and no loop-breaker in the harness (no cap on consecutive no-progress waits).

   2. The functions.exec fixation matches a real tool-registration gap, not just hallucination. #38960 (which the dedup bot linked) reports that the parent session in this configuration exposes only wait + collaboration tools — no exec. A model instructed to verify progress, with no execution tool in its registry, inventing functions.exec and then "reimplementing" it is exactly the failure shape you'd expect from that gap. Your transcript is effectively #38960's missing-exec plus the wait-starvation above compounding each other.

   Fix outline:

   1. Enrich the wait timeout result with a per-agent status snapshot (the states already exist — list_agents reads them); include whether each child is running/failed/never-started. A model that can see "child X failed to spawn" stops waiting for it.
   2. Make child death a completion of wait (terminal failure outcome) instead of an indistinguishable timeout.
   3. Harness-side loop-breaker: after N consecutive timed-out waits with zero agent-state change, fail the turn with a user-visible error rather than letting the loop burn tokens silently — your report's core harm is that "no error message is returned".
   4. Close the parent-session registry gap tracked in Windows Desktop 0.148-alpha.9: parent /root session has no exec, only wait + collaboration tools #38960 so verification work has a real tool instead of a phantom one.

   Also related for the maintainers triaging: #38989 documents runaway delegation in the same multi-agent v2 surface — (3) would bound the damage of that class too.
5. Dirard

   added 5 commits that reference this issue on Aug 27, 2026

   fix(code-mode): stop direct-tool routing loops

   ...

   5021113

   fix(code-mode): stop direct-tool routing loops

   ...

   ba76fad

   fix(code-mode): stop direct-tool routing loops

   ...

   c32a57a

   fix(code-mode): stop direct-tool routing loops

   ...

   baec81b

   fix(code-mode): stop direct-tool routing loops

   ...

   dc1f724
6. Dirard

   added 7 commits that reference this issue on Sep 18, 2026

   fix(code-mode): stop direct-tool routing loops

   ...

   a55c72a

   fix(code-mode): stop direct-tool routing loops

   ...

   f6c51b0

   fix(code-mode): stop direct-tool routing loops

   ...

   89cfe16

   fix(code-mode): stop direct-tool routing loops

   ...

   a130762

   fix(code-mode): stop direct-tool routing loops

   ...

   2f38e1a

   fix(code-mode): stop direct-tool routing loops

   ...

   809af7f

   fix(code-mode): stop direct-tool routing loops

   ...

   9977912