Codex Desktop task creation does not inherit no-approval full access

Open 💬 1 comment Opened Aug 27, 2026 by amoskueez
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

In Codex Desktop on macOS, newly created project tasks can request a manual approval for ordinary local Git writes even when the user-level configuration is set to no approvals and full local access.

This breaks voice-only workflows: a coordinator can create a project task, but the task stops for a click the user may not be able to make.

Expected behavior

A newly created local project task should inherit the effective approval and sandbox defaults of the desktop app. With no-approval and full-access settings active, ordinary local Git operations such as creating a branch, staging files, and committing should run without a manual prompt.

The app's internal task-creation tool should also support a durable pre-authorization option, so a voice coordinator can start an already-authorized project task without an additional manual confirmation.

When a user does allow a Git command and chooses the equivalent of allowing similar commands, subsequent matching Git commit operations should reuse that authorization.

Actual behavior

A newly created project task paused before creating a preservation branch, requesting permission to write Git metadata. This happened for simple local Git work in the selected repository. The task was created after the desktop settings had been changed to no approvals and full local access.

The same flow had to be retried in a new task and still encountered a permission prompt.

Separately, creating each project task through the Codex app's internal MCP tool prompted the user to allow the tool to create the task. This is not controlled by the no-approval/full-access settings and no persistent configuration option was visible for it.

After manually allowing a Git commit and selecting the option to allow similar commands, the same task prompted again for later Git commits. The grant did not persist across repeated commit operations.

Why this matters

The approval prompts are especially disruptive for voice-driven operation. The coordinator cannot accept a task-level prompt on the user's behalf, so a user without immediate keyboard access cannot continue an otherwise authorized workflow.

Requiring a manual confirmation to create the task and then further confirmations for ordinary Git work makes the voice flow stop-and-start rather than hands-free.

Reproduction outline

  1. In Codex Desktop on macOS, set approval policy to never and enable full local access.
  2. Start a voice conversation.
  3. Ask the coordinator to create a local project task that performs ordinary Git work, such as creating a branch and committing already-authorized changes.
  4. Observe the task-creation MCP confirmation.
  5. Observe that the new task may request manual approval for the Git write rather than inheriting the desktop defaults.
  6. Allow a Git commit using the option to allow similar commands, then observe a subsequent Git commit request another approval.

Related issues

  • #24934 reports approval prompts despite no-approval and full-access settings in the desktop app.
  • #15753 reports related macOS desktop approval prompts despite full-access settings.

This report is specifically about newly launched project-task contexts failing to inherit the parent desktop configuration, the absence of a durable authorization path for task creation in a voice-only workflow, and repeated Git prompts despite allowing similar commands.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 day ago

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

  • #41061

Powered by Codex Action