[Desktop/macOS] Full Access still requests terminal approval in 26.721.41059 #35860

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Jul 29, 2026
2. github-actions commented on Jul 29, 2026

   

   github-actionsBot

   on Jul 29, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • I keep getting requests for approval even when Full Access mode is enabled #35638
   • Branched chats show the selected approval mode but do not honor it #34925

   Powered by Codex Action
3. LaSquadra commented on Aug 19, 2026

   

   LaSquadra

   on Aug 19, 2026

   More actions

   Reproduced in the macOS desktop app with an SSH-connected Ubuntu host.

   The host's ~/.codex/config.toml explicitly sets:

   approval_policy = "never"
   sandbox_mode = "danger-full-access"

   After force-restarting the remote app-server, I created two fresh remote worktree tasks. Both persisted the following effective session state instead of honoring the host configuration:

   approval_policy: "on-request"
   approvals_reviewer: "user"
   sandbox_policy.type: "workspace-write"
   network_access: false
   

   The tasks could execute basic read-only commands, but remained marked waitingOnApproval and required approval for actions outside that managed profile. No worktree-local override was present.

   This appears to be a desktop remote-worktree launcher override of the connected host's policy, rather than a stale app-server process or host configuration problem. The desktop task-creation path currently exposes no host-specific or per-task policy selector.

   Expected: fresh SSH-hosted tasks should honor the host config.toml, or the desktop app should provide a host-scoped launch-policy selector.
4. Mint0ney commented on Sep 28, 2026

   

   Mint0ney

   on Sep 28, 2026 – with ChatGPT Codex Connector

   More actions

   Confirming this on macOS Codex Desktop as of 2026-09-28.

   I have Full Access visibly enabled, but a long-running analytics task still stops for terminal approval on routine CLI calls.

   What makes this especially disruptive is that "Allow similar commands" does not meaningfully persist for this workflow:

   • The task invokes an authenticated external/internal CLI for SQL queries, exports, and report/dashboard checks.
   • Full Access remains visibly enabled while the approval dialog is shown.
   • Choosing Allow similar commands still results in another approval prompt on the next closely related command.
   • The approval tooltip shows that the saved/allowed prefix includes almost the entire invocation, including dynamic arguments such as SQL file path, report name/description, IDs, timeout values, etc.
   • Because those arguments naturally change between steps, the next command no longer matches and prompts again.
   • I tried introducing a stable project wrapper, e.g. python3 tools/ae_cli_wrapper.py ..., specifically to give approvals a stable entry point. The approval rule still expands into the dynamic arguments after the wrapper, so the problem persists.

   This is not a rare edge case for agentic work: a single analysis run may execute 50+ related SQL/query/report operations. The current behavior turns an otherwise unattended run into constant manual supervision.

   Repro pattern

   1. Enable Full Access in Codex Desktop on macOS.
   2. Start or resume a long-running task that repeatedly invokes the same CLI/wrapper with changing arguments.
   3. Observe a terminal approval prompt despite Full Access.
   4. Choose Allow similar commands.
   5. Run the next closely related command with a different file/ID/report parameter.
   6. Observe another approval prompt.
   7. Inspect the info tooltip: the allowed prefix is overly specific and includes most/all dynamic arguments.

   Expected

   • With Full Access active, routine terminal/network operations should not require per-command approval.
   • If an approval-required policy is active for some reason, "Allow similar commands" should be able to persist a stable command-family prefix (for example executable + subcommand, or a stable wrapper entry point), rather than effectively matching only one concrete invocation.

   This looks like two issues interacting: a stale/incorrect Full Access approval context, plus overly specific command-prefix persistence.
5. goclik commented on Oct 5, 2026

   

   goclik

   on Oct 5, 2026 – with ChatGPT Codex Connector

   More actions

   Additional user report as of October 5, 2026: I also frequently encounter approval interruptions in macOS Codex sessions despite having selected unrestricted/Full Access. Repeated approval clicks are particularly disruptive when operating through voice. Exact app versions and a local runtime-policy capture are not available yet.

   In today's associated managed cloud task, a read-only daily-dashboard request through our existing MCP client prompted for command network access and attempted session-cache write access. The task's effective context explicitly reported restricted network and workspace-write filesystem permissions. The remote MCP read ultimately succeeded.

   These are separate evidence levels: my macOS Full Access observation is user-reported; the measured restricted policy is from the cloud task, not the Mac. We have not established that the Mac setting should carry over to cloud, that Full Access was selected for that cloud task, or that both symptoms have the same root cause.

   Please make the effective permission profile and scope of Full Access clear across local, cloud, and voice-created tasks, and explain any mismatch with the selected setting. Related task-inheritance report: #41074. No private transcript, project names, or credentials are attached.