Codex app ignores global Full access for sibling workspace and exposes no effective-permission control

Open 💬 2 comments Opened Jul 12, 2026 by hseshadr

Codex app version

26.707.51957

Platform

Darwin 25.5.0 arm64 (macOS 26.5, build 25F71)

Subscription

Paid account; exact tier is not relevant to the reproduction.

What issue are you seeing?

The Codex app is globally configured for Full access, but an existing task remains silently pinned to a managed workspace-write / on-request profile. Work inside the task root proceeds, while every write or test-cache operation in a sibling repository triggers another approval. The conversation UI does not show an effective-permission selector, shield control, or writable-root list, so the user cannot discover or correct the mismatch.

Persistent approvals also feel inconsistent: approving a command or related prefix reduces some prompts, but ordinary follow-on git/test operations still trigger separate approval dialogs. This makes a long multi-repository task impractical even though the global setting says Full access.

Reproduction steps

  1. In Codex app settings, select Full access / the least-interruptive approval mode.
  2. Open a task rooted at /Users/me/dev/project-a.
  3. In the same task, ask Codex to review and update /Users/me/dev/project-b, a sibling repository.
  4. Approve the first write/test/git operation and choose the persistent approval option when offered.
  5. Continue the workflow with tests, staging, commits, and other normal operations in project-b.
  6. Observe repeated approval prompts. The task effectively behaves as workspace-write / on-request, but there is no visible task-level control or explanation of the effective writable roots.

The assistant may infer that a task-level shield/permissions control exists and direct the user to it, but no such control is present in this app build.

Expected behavior

One of the following should happen:

  • The global Full access setting applies to the task, including explicitly requested sibling repositories; or
  • the task clearly displays its effective permission profile and writable roots, with a real control to change them; or
  • the app offers one scoped approval to add /Users/me/dev/project-b as a writable root for the remainder of the task.

A persistent approval should cover the displayed command category reliably. The app should never direct users toward a permission control that is absent from the installed UI.

Additional information

No credentials, private repository names, session identifiers, or screenshots are included. The mismatch is reproducible during ordinary multi-repository engineering work.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗