Codex app ignores global Full access for sibling workspace and exposes no effective-permission control
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
- In Codex app settings, select Full access / the least-interruptive approval mode.
- Open a task rooted at
/Users/me/dev/project-a. - In the same task, ask Codex to review and update
/Users/me/dev/project-b, a sibling repository. - Approve the first write/test/git operation and choose the persistent approval option when offered.
- Continue the workflow with tests, staging, commits, and other normal operations in
project-b. - 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-bas 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.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗