Skip to content

Full access selection still starts sessions with workspace-write sandbox #29503

Open
Open
Full access selection still starts sessions with workspace-write sandbox#29503
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxing

Description

@KJ21-ENG
KJ21-ENG
opened on Jun 23, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    sandboxIssues related to permissions or sandboxing
    on Jun 23, 2026

  2. github-actions commented on Jun 23, 2026

    @github-actions
    github-actionsbot
    on Jun 23, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. gm-fire commented on Jun 24, 2026

    @gm-fire
    gm-fire
    on Jun 24, 2026

    Adding another reproduction from the Codex Desktop app on macOS.

    Environment:

    Codex Desktop: 26.616.81150, bundle 4306
Codex CLI: 0.142.0
macOS: 15.3.1 (24D70), arm64
Current Codex originator: Codex Desktop

    Observed behavior:

    • The user-facing permissions UI was set to Full access.
    • After quitting Codex Desktop and reopening the project/thread, a later Git staging operation failed while creating the Git index lock:
    fatal: Unable to create <workspace>/.git/index.lock: Operation not permitted
    • The affected turn appeared to have an effective sandbox like workspace-write with the workspace root writable but .git treated as read-only, so ordinary workspace edits were possible but git add could not write .git/index.lock.
    • In a fresh side conversation in the same project after reopening, the effective metadata shows full access again:
    sandbox_policy: { type: danger-full-access }
permission_profile: { type: disabled }
approval_policy: never
    • A direct non-persistent write probe under .git succeeded in that fresh side conversation, and .git/index.lock was not present. So this does not look like a macOS file ownership issue or a stale lock file. It looks like a Codex Desktop permission-state / session-resume mismatch: the UI can show Full access, while the affected agent turn is still running with a restricted sandbox snapshot where Git metadata is blocked.

    Expected behavior:

    If the UI says Full access for a local project, resumed threads and side conversations should get the same effective danger-full-access permissions, or the UI should clearly show that an older/restricted sandbox snapshot is still active for that turn.

    Privacy note: I have intentionally replaced the local user and repo path with <workspace> because this is a public issue. I can provide more exact session details through a private/support channel if useful.

  4. briancl2 commented on Aug 6, 2026

    @briancl2
    briancl2
    on Aug 6, 2026 – with ChatGPT Codex Connector

    Adding bounded macOS Desktop evidence from a public, sanitized investigation: https://github.com/briancl2/build-meta-analysis/issues/1559#issuecomment-5207186363

    In one fresh-parent transfer, five fresh visible destinations resolved to approval_policy=on-request / sandbox_mode=workspace-write while the source task and local configured/default state were never / danger-full-access. Sanitized turn_context evidence places the first observed divergence in the Desktop/high-level fresh-task request assembly: app-server resolved the explicit restrictive fields it received.

    Controls in the same episode matter:

    • the same parent after Stop resolved back to never/danger-full-access;
    • an internal subagent control was unrestricted;
    • a later manually activated fresh task was unrestricted.

    That falsifies a config-only, app-server-only, model-only, and universal-fresh-task explanation for this bounded case. It supports an atomic activation contract plus a requested/resolved permission receipt with provenance/revision, before the first model/tool action.

    Claim ceiling: one macOS Desktop transfer/build family; no all-host recurrence rate or internal code-location claim.

  5. alexph-dev commented on Oct 13, 2026

    @alexph-dev
    alexph-dev
    on Oct 13, 2026

    Additional local-to-local macOS evidence, observed October 13, 2026.

    Environment: Desktop 26.1007.30912, build 20156; child runtime 0.162.0-alpha.17.2. Both the parent and the created chat ran on the same Mac. No remote server or remote handoff was involved.

    Observed sequence:

    1. An existing local chat used the built-in create_thread tool to create a chat in another local project with environment.type = local, without a worktree. The parent's persisted turn context was approval_policy=never, sandbox_policy.type=danger-full-access, and permission_profile.type=disabled.

    2. Before the child's first model action, the Desktop log recorded these explicit launch fields:

      requestApprovalPolicy=on-request
requestApprovalsReviewer=user
requestPermissionProfile=:workspace
resolvedApprovalPolicy=on-request
useAppServerPermissionDefault=false

    3. The child's persisted first-turn context confirmed:

      approval_policy=on-request
sandbox_policy.type=workspace-write
sandbox_policy.network_access=false
permission_profile.type=managed

    4. The user observed Full access in the composer while the chat required approval. Ordinary command networking failed with a DNS-resolution error, and Desktop recorded a command-execution approval request.

    5. After the user selected Full access and continued, Desktop sent requestApprovalPolicy=never and requestPermissionProfile=:danger-full-access. The next persisted turn context confirmed never / danger-full-access / disabled, and the network command succeeded through ordinary execution.

    The current user configuration and saved local-host preference also select Full access. Those are corroborating current observations, not historical proof of the preference at creation; the parent's actual full-access turn context and the child's restrictive launch receipt establish the local-to-local discrepancy directly.

    This points to the Desktop task-creation path supplying restrictive settings for this occurrence. It does not establish the internal reason for choosing them, a recurrence rate, or that every related resume/Dots report shares the same cause. We have not run a fresh controlled reproduction. A separate long-running browser-tool wait occurred in this chat; we are not attributing that delay to this permission mismatch.

    Please investigate permission propagation for agent-created local chats, make the displayed access mode reflect the effective runtime policy, and expose the source of any intentional override. This interrupts unattended delegation even when both chats run on the same computer.

    Only sanitized technical evidence is included here. No names, usernames, local paths, account/project/chat identifiers, business data, raw logs, or screenshots are attached. Prepared with Codex assistance and posted with the account owner's approval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions