[Windows][GPT-6 Astra] Approval dialog hides the actual action being authorized and enters repeated approval loops

What version of the Codex App are you using (From “About Codex” dialog)?

Version: 26.901.51231

What subscription do you have?

Pro

What platform is your computer?

Windows 11 25H2 Build 26200.9278

What issue are you seeing?

[Windows][Codex Desktop][GPT-6 Astra] Approval UI does not disclose the action being approved and repeatedly interrupts ordinary local work

Summary

I consider the current GPT-6 Astra approval/safety workflow in Codex Desktop to be a serious safety and usability regression.

When using GPT-6 Astra, Codex repeatedly interrupts ordinary, non-destructive local development work with a safety/approval dialog.

The critical problem is that the dialog does not clearly show the actual operation that I am being asked to authorize.

Instead, it repeatedly displays what appears to be a summary of Astra's findings/reasoning and asks me to check a box similar to:

"I confirm that I have reviewed everything"

and then click a confirmation button.

As a user, I therefore cannot reliably determine:

• what command/tool call is about to be executed;
• which file, directory, process, service or resource will be affected;
• whether the operation is read-only or modifies something;
• what permissions I am granting;
• what the scope of the approval is;
• whether I am approving one operation or allowing a broader continuation;
• what exactly will happen after I press Continue.

This defeats the primary purpose of an approval boundary: the user should know exactly what they are authorizing before authorization is granted.

Strong Astra vs. Sol reproduction

This behavior appears to be specifically associated with GPT-6 Astra / its Codex approval-review flow.

I performed a direct comparison in the same Codex environment.

With:

GPT-6 Astra

the problematic approval/safety dialogs repeatedly appear.

After switching the same work to:

GPT-5.6 Sol

the problem disappears completely and the normal, understandable Codex approval behavior returns.

This makes the issue reproducible as a model-dependent behavior rather than a general inability to use Codex permissions.

Explicit instruction does not prevent the problem

I explicitly instructed Astra:

Work independently. Do not ask for approval for ordinary reading and safe work with local project files. Request approval only for destructive operations or actions with significant impact on infrastructure or its resources.

Astra acknowledged the instruction.

However, the safety/approval system continued interrupting ordinary local audit work.

Repeated approval loop

The problem is not limited to poor wording of the approval dialog.

The approval system can enter what appears to be a repeated interruption/restart loop.

For example, at approximately 14:03 local time I received several consecutive partial responses:

"Understood, I will perform ordinary reading and safe local work independently. I am completing the audit..."

Then again:

"Understood, I will complete ordinary reading and the local audit independently..."

Then again:

"Understood, I will complete ordinary local work independently..."

Then again another nearly identical start.

Each time Astra appeared to begin or resume the task, it was interrupted by the safety dialog.

I had to repeatedly:

1. read the same or similar safety dialog;
2. check the confirmation checkbox;
3. press the confirmation button;
4. allow Astra to continue;
5. watch it begin another nearly identical response;
6. encounter another safety interruption.

This can happen repeatedly within a very short period.

The approval dialog appears to show the wrong information

The most serious part of the issue is the mismatch between what the user sees and what the user apparently authorizes.

The dialog prominently presents Astra's initial findings or assessment.

That information effectively masks the operation that requires authorization.

I would expect an approval dialog to explicitly show information such as:

• requested operation/tool;
• exact command, where applicable;
• target path/resource;
• working directory;
• whether the operation reads or writes;
• affected files/resources;
• network or remote destination, if applicable;
• requested permission scope;
• whether approval applies once or persistently;
• expected effect of pressing Approve/Continue.

Instead, I am asked to confirm that I reviewed information which does not clearly identify the operation being authorized.

I cannot responsibly confirm that I have reviewed an operation if Codex does not show me that operation.

Safety impact

I consider this more than a UX inconvenience.

Codex is an agent capable of:

• modifying files;
• executing PowerShell/shell commands;
• using Git;
• running scripts;
• accessing databases;
• interacting with development infrastructure;
• potentially interacting with remote systems depending on the user's environment and permissions.

For an approval mechanism protecting these capabilities, informed user authorization is essential.

If the approval UI does not disclose the actual operation and scope being authorized, users can approve an action without understanding what they have permitted.

The UI should never make the user attest that they have "reviewed everything" while withholding or obscuring the concrete action that is being approved.

Productivity and usage/quota impact

The repeated safety interruptions also make Astra practically unusable for autonomous Codex work.

Astra repeatedly starts/resumes work, gets interrupted, produces another partial response, and is interrupted again.

This creates unnecessary model turns and context processing without completing useful work.

As a result:

• tasks take substantially longer;
• autonomous operation becomes impossible;
• the user has to supervise trivial local work;
• repeated near-identical responses are generated;
• Codex usage/credits may be consumed by repeated interrupted attempts without proportional useful progress.

The difference is immediately noticeable compared with GPT-5.6 Sol.

Expected behavior

For ordinary safe local operations, Astra should respect the configured/requested permission policy and work autonomously.

When an operation genuinely requires user approval, the dialog should clearly identify the exact operation being authorized.

At minimum, the user should be able to answer:

"What exactly will Codex do if I click Approve?"

without having to infer the answer from previous model output.

After a user explicitly approves a specific operation, Codex should not immediately enter another approval loop for the same operation/context unless a materially different risk or action has appeared.

Actual behavior

With GPT-6 Astra:

• ordinary local work repeatedly triggers safety interruptions;
• explicit instructions to avoid unnecessary approvals do not resolve it;
• the approval dialog focuses on findings/context instead of clearly exposing the pending operation;
• the user is asked to attest that they reviewed everything;
• the actual authorization scope is unclear;
• approving the dialog can lead almost immediately to another similar dialog;
• Astra repeatedly produces near-identical restart/resume messages;
• useful work progresses very slowly or not at all;
• unnecessary usage/quota appears to be consumed.

Switching to GPT-5.6 Sol immediately eliminates the behavior in the same workflow.

Why I consider this critical

An approval mechanism is a security boundary.

A security boundary should never rely on a user approving an operation whose identity and scope are not clearly disclosed.

The current Astra behavior creates the opposite of informed approval: the interface demands confirmation while making it difficult or impossible for the user to understand precisely what is being confirmed.

Until this is fixed, I do not consider GPT-6 Astra suitable for Codex workflows where the agent has meaningful write, execution, database, Git, deployment, administrative or infrastructure permissions.

Requested investigation

Please investigate:

1. Why GPT-6 Astra triggers this approval/auto-review flow while GPT-5.6 Sol does not in the same environment.
2. Why ordinary local code reading/auditing repeatedly triggers the safety dialog.
3. Why the approval dialog does not prominently display the exact pending tool call/command/action.
4. What permission scope the checkbox/Continue action actually grants.
5. Why explicit user approval can be followed immediately by another substantially identical safety interruption.
6. Why Astra repeatedly restarts/resumes with near-identical messages after each interruption.
7. Whether these interrupted/restarted turns are consuming Codex quota/credits.
8. Whether the Guardian/Auto-review layer is overriding the user's selected permission policy or explicit instructions.
9. Whether this approval UI satisfies the intended security requirement that users understand the action they are authorizing.

I strongly recommend treating this as a safety/security UX regression rather than merely an inconvenience or feature request.

Environment

• Platform: Windows
• Product: ChatGPT Desktop / Codex
• Model exhibiting the problem: GPT-6 Astra
• Comparison model without the problem: GPT-5.6 Sol
• Date reproduced: September 8, 2026
• Reproducibility: repeated
• Switching Astra → Sol: immediately resolves the issue

What steps can reproduce the bug?

1. Open an existing local project in Codex Desktop on Windows.

2. Select GPT-6 Astra as the model.

3. Give Astra a normal non-destructive development task, such as reading project files and auditing existing code.

4. To make the intended permission behavior explicit, I used this instruction:

   "Work independently. Do not ask for approval for ordinary reading and safe work with local project files. Request approval only for destructive operations or actions with significant impact on infrastructure or its resources."

5. Astra acknowledges the instruction and starts working.

6. During ordinary local read/audit work, Codex interrupts the task with a safety/approval dialog.

7. The dialog does not clearly identify the concrete operation/tool call/command that is being authorized. Instead, it primarily displays a summary of Astra's findings/context and asks me to check a box confirming that I have reviewed everything before I can continue.

8. Check the confirmation box and click the button to continue.

9. Astra resumes, but shortly afterwards the same or substantially similar safety dialog appears again.

10. Repeat the confirmation. Astra may repeatedly restart/resume its response with nearly identical text and get interrupted again.

For example, during one reproduction I received several consecutive responses within the same minute beginning with variations of:

• "Understood, I will perform ordinary reading and safe local work independently..."
• "Understood, I will complete ordinary reading and the local audit independently..."
• "Understood, I will complete ordinary local work independently..."

Each attempt was interrupted by the approval/safety flow.

Control test

11. Switch the model from GPT-6 Astra to GPT-5.6 Sol, without otherwise changing the project/workflow.

12. Repeat the same type of task.

Result: The problematic repeated approval flow disappears and normal Codex approval behavior returns.

I can reproduce the problem with Astra, while switching to Sol immediately resolves it.

What is the expected behavior?

GPT-6 Astra should behave consistently with the configured Codex permission model and should not repeatedly interrupt ordinary, non-destructive local development work.

For normal operations such as reading project files, analyzing code, searching the repository, and performing a local audit, Astra should continue autonomously without requesting approval.

When an operation genuinely requires user approval, the approval dialog should clearly and prominently show exactly what action is about to be authorized, including where applicable:

• the tool or operation being executed;
• the exact command;
• the target file, directory, process, service, database, or remote resource;
• whether the operation is read-only or will modify something;
• the expected effect of the operation;
• the scope and duration of the permission being granted.

The user should be able to answer the following question before clicking Approve:

"What exactly will Codex do if I approve this?"

After the user approves a specific operation, Codex should continue the task and should not immediately request substantially the same approval again unless a new or materially different privileged/risky operation is required.

The approval system should also not repeatedly restart Astra's response or cause near-identical model turns without useful progress.

Finally, switching between GPT-6 Astra and GPT-5.6 Sol should not fundamentally change the transparency of the security boundary. A more capable model may require different safety evaluation, but the user must always be clearly informed about the concrete action they are authorizing.

Additional information

Additional information

This issue is particularly concerning because the approval dialog appears to act as a security boundary, yet it does not clearly disclose the concrete action being authorized.

This is not merely a complaint about Astra being overly cautious or showing too many safety checks. The primary concern is that the user is required to explicitly confirm that they have reviewed the situation and then approve continuation, while the UI does not make it clear what specific operation will be performed as a result of that approval.

In my testing, the dialog repeatedly shows essentially the same initial findings/context rather than clearly showing the pending command, tool call, target resource, or permission scope.

There are two separate problems:

1. Authorization transparency: I cannot reliably determine what action I am authorizing.
2. Repeated approval loop: after confirming the dialog, Astra resumes briefly and can immediately trigger another substantially identical approval dialog during ordinary local work.

The second problem also appears to cause unnecessary model usage. Astra repeatedly starts/resumes the task, generates another partial response, gets interrupted, and repeats the process without making proportional useful progress. This may unnecessarily consume Codex usage/credits.

A/B test

The strongest indication that this is related specifically to the Astra integration/approval flow is a direct comparison:

Same Codex installation + same project + same type of task + GPT-6 Astra = problem consistently reproduced.

Switching only the model to:

GPT-5.6 Sol = problem disappears completely.

No project permission or workflow changes were necessary.

Switching back to Astra causes the problematic behavior to return.

Security concern

Because Codex can execute commands and modify local or potentially connected resources, I believe an approval dialog must always make the pending action and its scope explicit before the user authorizes it.

I am not claiming malicious intent or that Astra is performing unauthorized actions. My concern is that the current UI makes informed authorization difficult or impossible because the user cannot clearly see what operation their confirmation actually permits.

For that reason, I currently do not consider Astra safe to use in Codex for workflows with meaningful write, execution, Git, database, deployment, administrative, or infrastructure permissions.

Evidence available

I can provide:

• screenshots of the repeated approval dialog;
• screenshots showing multiple nearly identical interrupted Astra responses within the same minute;
• exact timestamps;
• Codex Desktop version;
• additional reproduction attempts comparing Astra and GPT-5.6 Sol.

The issue was reproduced repeatedly on September 8, 2026 on Windows.

No source file, test, or code entry point is identified. Reproduce the workflow in Codex Desktop on Windows with GPT-6 Astra, then compare it with GPT-5.6 Sol using the described local audit task. Done means the approval dialog identifies the pending action and scope, and approving one action does not cause repeated equivalent interruptions.