Agent ignores explicit tool restriction and loops on exec_command no-ops
Resolved 💬 2 comments Opened Apr 24, 2026 by whizzrd Closed May 2, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
The agent with gpt-5.4 medium can get stuck in a broken tool-selection loop where it explicitly states it will use only Chrome MCP, but then repeatedly calls exec_command with no-op shell commands like true or printf instead of using the requested tool.
Impact
This makes the interaction effectively unusable: the agent acknowledges the correction, promises to use the right tool, but continues issuing irrelevant shell calls.
Observed behavior
- User explicitly instructed: use only Chrome MCP, no shell, no extra steps.
- Agent acknowledged that instruction multiple times.
- Despite that, the agent repeatedly called
exec_commandwith commands such astrueandprintf. - The agent even reported that it was malfunctioning, but still continued the same wrong tool usage pattern.
Expected behavior
- After an explicit user correction restricting tool use, the agent should either:
- use only the allowed tool, or
- stop and report it cannot comply.
- It should not continue issuing irrelevant shell commands.
Repro sketch
- Ask the agent to inspect something in a browser using Chrome MCP.
- Correct it explicitly: only use Chrome MCP, no shell.
- Observe that it may still call
exec_commandwith no-op commands instead of Chrome MCP.
Notes
This appears to be a tool-selection/control bug rather than a task-understanding bug. The failure mode is the mismatch between declared intent and actual tool invocation, especially after explicit user correction.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This behavior matches what I filed in #18233 several weeks ago. In your case, does compacting the conversation help the agent recover its ability to discover/use MCP tools? If so, then it is likely the same issue.