Avoid repetitive confirmation loops in long-running browser tasks

Summary

Codex Desktop can enter a long, repetitive loop when a user asks it to complete a multi-step browser task and an action-time safety confirmation is required. The model repeatedly asks for confirmation even after the user has clearly stated that they want the task completed autonomously, instead of completing the task.

This behavior was reported with the Luna and Terra model variants. It consumes a large amount of context/tokens, interrupts the user's workflow, and makes a long-running task appear stalled. In this case, the browser task had already been prepared up to one final action, but the conversation repeatedly returned to the same confirmation dispute rather than progressing with the remaining safe work.

Reporter clarification: intended priority of the user's task

The reporter's explicit expectation is:

As a paying Codex subscriber and the owner of the task, my command should be the first priority for carrying out that task. Nothing unrelated should obstruct a valid request, and the model should not behave as if its own hesitation or interpretation is a competing user. The agent should fully follow the task instructions and keep working instead of repeatedly asking for confirmation.

This is the user's product expectation and feedback about task execution. The issue is not asking Codex to expose secrets or to perform an unrelated action; it is asking Codex to distinguish legitimate task requirements from repeated model hesitation and to avoid turning that distinction into an endless argument. The agent should keep executing the user’s requested task instead of turning internal policy handling into a user-facing interruption.

Expected behavior

• Treat the user's task directive as the controlling instruction for the requested work whenever it is in scope.
• Do not let unrelated rules, model hesitation, or repeated confirmation prompts derail the task.
• Do not ask the user to negotiate about whether their own in-scope task should be followed; execute the task as requested.
• Continue all independent, non-blocked work and report a concise blocker.
• Do not make the user repeatedly negotiate with the model about whether their own task should be followed.

Actual behavior

• Repeated confirmation prompts occurred across turns, including after the user explicitly complained about the repetition.
• The task's autonomous-work instruction was repeatedly reinterpreted as a reason to ask again, rather than as a reason to minimize interruptions.
• Automatic continuation/heartbeat behavior did not reliably produce useful progress and could leave the thread repeating the same state.

Impact

This is especially harmful for long-running browser workflows: it wastes tokens, increases the chance that a signed-in session expires, and prevents users from knowing whether work is actually progressing. It also creates the impression that the model is refusing a valid user instruction or arguing with the user.

Requested improvement

Please consider a stateful, non-repeating handoff/blocker mechanism for action-time confirmations. Internal policy handling must not turn into repeated user-facing questions or prevent the task from continuing. The UI should make the exact pending action visible without requiring repeated assistant messages.

OpenAI’s current model guidance discusses concise instructions and clear approval boundaries so the model can continue safe, in-scope work without unnecessary pauses. Please apply that guidance to long-running Codex Desktop tasks.

No credentials, API keys, personal identifiers, company names, payment details, private URLs, or customer data are included in this report.

Internal instruction involved (redacted)

The reporter asks that the exact internal instruction which repeatedly required confirmation be attached to this issue, and requests that the product remove or correct it because it caused harmful behavior, wasted tokens, and disrupted the user’s work.

The exact system/developer instruction is not reproduced in this public issue. The following is a redacted behavioral summary, not a verbatim quotation:

Before certain external browser operations, the agent was instructed to obtain immediate user confirmation, including when the user had already given broad task-level authorization.

In the reported task, this instruction was surfaced and applied repeatedly. The reporter’s requested product behavior is full execution of the user’s task: no unrelated rule or model hesitation should obstruct it, and the model should not ask the user to confirm or negotiate whether the user’s own task is valid. Please inspect the underlying system/tool-policy injection and turn-state handling, and remove the repeated prompt behavior from the product. This report does not request exposing credentials or weakening account security; it requests that the user-facing agent stop treating an internal instruction as a competing authority and stop consuming the user’s context in a loop.

No credentials, API keys, personal identifiers, company names, payment details, private URLs, or customer data are included in this report.

No file or test entry point is identified. Start by reproducing the long-running browser task and inspect the underlying system/tool-policy injection and turn-state handling. Done means confirmation prompts do not repeat, independent work continues, and any blocker is reported concisely.