›_ Codex Issues
Codex Issues / #22245

/goal` mode repeatedly emits dangerous-operation confirmation prompt and consumes quota

Resolved 💬 5 comments Opened May 12, 2026 by wantMeat Closed May 30, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

20x

Which model were you using?

/goal gpt-5.5-codex

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

When using /goal mode, a task triggered the dangerous-operation confirmation rules from AGENTS.md.

The agent correctly detected that the task involved deleting files and asked for explicit confirmation, but it did not
pause while waiting for the user response. Instead, it repeatedly emitted the same dangerous-operation confirmation
prompt and kept consuming quota.

The repeated prompt was essentially:

  • Dangerous operation detected
  • Operation type: delete files
  • Scope: 21 non-integration test files under the course service directory
  • Please confirm whether to continue: “yes”, “confirm”, or “continue”

After that, it repeatedly stated that confirmation was still missing, so it could not delete the files and could not
mark the goal complete.

Expected behavior: once confirmation is required, /goal should stop and wait for the user. It should not keep
regenerating the same prompt or consume additional quota while blocked on confirmation.

What steps can reproduce the bug?

  1. Create or use a project with an AGENTS.md file that requires explicit confirmation for dangerous operations such

as deleting files.

  1. Start a task using /goal.
  2. Ask the agent to perform a task that includes deleting multiple files.
  3. Let the agent detect the dangerous operation and ask for explicit confirmation.

```text
Dangerous operations require explicit confirmation before proceeding.
Deleting files is considered dangerous.
Actual result: /goal repeatedly emits the confirmation prompt and consumes quota.

Expected result: /goal enters a blocked/waiting-for-user-confirmation state after the first prompt.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22158

Powered by Codex Action

etraut-openai contributor · 3 months ago

/goal works by waiting for a turn end, then injecting a new synthetic prompt to tell the agent to evaluate whether the goal has been achieved. If the goal has not been achieved, the agent is instructed to keep working toward the goal.

If the agent attempts to access a resource that is blocked by the sandbox and you have configured an "ask for approval" approval policy, codex will wait for a response before continuing with the turn.

If you are providing instructions in your AGENTS.md file to tell the agent to stop its turn if it attempts to do something dangerous, then you're giving it conflicting instructions when you define a /goal. You're telling it "stop under condition A and keep going unless condition B is met".

You can avoid this conflict by incorporating the "dangerous operation confirmation" as part of your goal completion definition, as in /goal do X until Y or you are blocked by a dangerous operation that requires human approval.

Tuo-Luo · 3 months ago

I documented a related workaround here: #23067.

The approach is to make repeated blocking conditions part of the goal completion criteria up front, so /goal can terminate the continuation loop when it keeps hitting the same blocker, without treating the blocked action itself as completed.

daoyuantang · 3 months ago

Adding another affected-user report because this has material quota impact, not just UI noise.

I hit the same class of /goal behavior when the session reached a user-authorization gate. Goal mode kept listening/continuing and repeatedly sent prompts asking me to authorize instead of entering a single blocked/waiting state. It did not make progress while blocked, but it continued consuming my weekly Codex allowance; this run used roughly 20% of my weekly quota before I noticed and stopped it.

Why I think this should be handled by Codex rather than only as a user prompt or AGENTS.md workaround:

  • When a continuation is blocked on a user action/authorization, the agent cannot satisfy the goal until the user responds.
  • Re-entering continuation with the same blocker is a no-op and has a direct billing/quota cost.
  • The UI/runner should treat "waiting for user authorization" as a terminal blocked state for the current continuation cycle and suppress repeated prompts until the user acts.
  • If a goal resume is attempted automatically, it should detect the repeated blocker and stop after the first occurrence, or mark the goal as blocked with the blocker reason.

Expected behavior:

  1. The first authorization prompt is shown once.
  2. /goal pauses in a waiting-for-user state.
  3. No synthetic continuation turns are generated while the prompt is unanswered.
  4. The blocked state is visible to the user, and the goal resumes only after explicit user input.

Related issues I found while checking for duplicates:

  • #22158: infinite loop in /goal while blocked.
  • #23067: proposal/workaround for repeated blocking conditions.
  • #17623: repeated permission prompts/reusable approval scope.
etraut-openai contributor · 3 months ago

I'm working on a fix.