Full access selection still starts sessions with workspace-write sandbox

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

Version 26.616.51431

Note: the app bundle was not visible to the agent under /Applications/Codex.app, so this version is taken from the active Codex app/tool metadata for the affected session.

What subscription do you have?

Not exposed to the agent runtime. The reporter can update this with the exact plan if needed.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

After selecting Full access in the Codex app permissions/access selector, new/local sessions still appear to be launched with an effective sandbox configuration of workspace-write, not full unrestricted access.

In the affected session, the runtime metadata exposed to the agent showed:

sandbox_mode: workspace-write
approval_policy: never
writable_roots:
  - /Volumes/MacSSD/Development/CursorAI_Project/App-1
  - /Volumes/MacSSD/tmp
  - /private/tmp

This was surprising because the UI access selection had been set to Full access. The agent therefore kept reporting that it was operating inside a sandbox, and some operations behaved as sandboxed even inside the selected workspace.

One concrete symptom was a Git metadata write failing while trying to update the local index under the workspace:

fatal: Unable to create '<workspace>/.git/index.lock': Operation not permitted

The workspace files themselves were readable and writable, but the effective permissions did not match the user's selected Full access mode.

What steps can reproduce the bug?

1. Open the Codex app on macOS.
2. Open a local project/workspace.
3. In the permissions/access selector under the composer, select Full access.
4. Start a new thread or side conversation in that project.
5. Ask Codex to inspect or report the effective runtime permissions/sandbox state, or run an operation that writes Git metadata such as updating the index.
6. Observe that the agent reports workspace-write / sandboxed permissions instead of danger-full-access, and Git metadata writes may fail with Operation not permitted.

Expected session details that are relevant:

Expected full access: sandbox_mode = danger-full-access, approval_policy = never
Observed effective access: sandbox_mode = workspace-write, approval_policy = never

What is the expected behavior?

When the user selects Full access, the effective runtime for new local sessions should match the documented full-access behavior, i.e. sandbox_mode = "danger-full-access" with approval_policy = "never", unless an organization or config policy is overriding it.

If a repo/user/org config or managed requirement forces workspace-write, the app should make that explicit in the UI so the visible selector does not imply Full access while the agent is actually sandboxed.

Additional information

The behavior seems recent. The user reports that they did not see Codex repeatedly mention the sandbox environment in earlier sessions after selecting Full access.

Possible areas to check:

• Whether the Codex app UI selection is being applied to side conversations and newly created threads.
• Whether project/user/team config is overriding the app selector without surfacing that in the UI.
• Whether permission profiles and legacy sandbox_mode settings are interacting unexpectedly.
• Whether .git paths inside the current workspace root are being protected differently from ordinary workspace files in workspace-write mode.

I searched the open issue list for the exact Full access / workspace-write / danger-full-access mismatch before filing and did not find an exact duplicate. There are recent sandbox-related Codex App issues, but they appear to describe different Windows/WSL symptoms rather than this macOS Full access selector mismatch.