/goal looping through execution-time permission request burning through 25% weekly usage limits doing nothing
Resolved 💬 6 comments Opened May 15, 2026 by EatMyTarts Closed May 30, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.513.20950
What subscription do you have?
Pro
What platform is your computer?
macOS
What issue are you seeing?
Codex 5.5 Medium despite AGENTS.md, developer instructions, and prompting seems to get stuck in loops while in goal mode that cause it to seek verbal confirmation before it acts. This has happened a few times. This time, it got stuck doing it all night and burned through 25% of my weekly Pro usage limits asking for "explicit billing confirmation". Not acceptable.
What steps can reproduce the bug?
Feedback ID: 019e28dd-7992-7892-a1ce-0e82108da4d6
What is the expected behavior?
Stop seeking verbal confirmation after a user requests an action, especially if permissions are set. Especially don't seek it out when in /goal and get stuck on a loop all night asking for confirmation via chat.
Additional information
_No response_
6 Comments
The
/goalfeature works by compelling the agent to work toward the specified objective until the completion criteria are met. It sounds like you have provided conflicting completion criteria in that you've provided instructions to the agent to stop under certain circumstances. The/goalfeature will override this unless you provide the same stopping criteria in the goal objective.I'm working on a change that will address this.
I've updated the
/goalfeature to allow the agent to stop if and when it hits an impasse. This prevents it from going into a permanent loop.What usually makes this expensive is not the first blocker, it is the repeated blocker. If the same permission failure shows up again without any new state, the run should stop or downgrade instead of asking again and burning more cycles. The runtime rule I would want is: hash the blocker, track repeated no-progress retries, and emit a typed blocked receipt once it is clear nothing changed. We ended up building MartinLoop around that exact failure pattern because most painful agent failures look like polite repetition, not dramatic crashes.
This feels like a missing run contract more than a missing model capability. When the same blocker repeats, the loop should stop or downgrade instead of consuming more budget asking the same thing again. The minimum contract I'd want is blocker-hash dedupe, a hard spend cap for the run, and a typed blocked receipt so the parent system can tell the difference between waiting, retrying, and actually stuck. Making the stop reason explicit matters more than making the loop more persistent.
This has already been fixed 😂