Skip to content

[macOS/dots] Tasks created by dots show Full access but delegated follow-up turns remain restricted #50671

Open
Open
[macOS/dots] Tasks created by dots show Full access but delegated follow-up turns remain restricted#50671
Labels
appIssues related to the Codex desktop appbugSomething isn't workingdotsIssues involving setting up ChatGPT dots or managing their ongoing work.sandboxIssues related to permissions or sandboxing

Description

@Azad-Zhang
Azad-Zhang
opened on Oct 3, 2026

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

26.928.31416 (12553), verified from installed application metadata.

What subscription do you have?

Not disclosed in this public report; can be provided through an official private support channel if needed.

What platform is your computer?

macOS.

What issue are you seeing?

I use dots. I asked my dot to create a task, opened that exact task in the desktop app, and selected Full access in its permission menu. Both the menu checkmark and the composer showed Full access for the affected task.

When I then asked the dot to continue the same task, the subsequent delegated turn still reported sandbox_mode=workspace-write and approvals_reviewer=auto_review.

A manually created local desktop task on the same computer correctly uses Full Access. The dots creation and follow-up path is the important distinction in this report.

Workflow details:

  • Affected workflow: dots conversation → dot creates a task → select Full access in that task's desktop UI → dot continues the same task.
  • The affected task's metadata reports hostId=durable; the manual local control reports hostId=local. These metadata values alone are not being treated as proof of the cause.

What steps can reproduce the bug?

  1. In a dots conversation, ask the dot to create a task.
  2. Open the created task in the desktop app.
  3. Select Full access in that task's permission menu. Confirm that the menu checkmark and composer both show Full access.
  4. Ask the dot to continue that same task, starting a subsequent turn rather than creating another task.
  5. Inspect the effective execution-permission context using read-only diagnostics.

The affected task was visually confirmed to be the correct task. This was not merely enabling the Full access option in global settings, and the choice was not made in a different parent conversation.

What is the expected behavior?

If Full access is supported and permitted for this task, the selected mode should apply to its subsequent turns, including follow-ups delivered through dots.

If this creation path or an enforced policy prevents the selection from taking effect, the task UI should display the effective mode and explain the restriction instead of presenting Full access as selected without qualification.

Additional information

Sanitized diagnostic evidence

A locally persisted permission snapshot associated with the affected task contains this mixed state:

activePermissionProfile.id = :danger-full-access
approvalPolicy = never
approvalsReviewer = user
sandboxPolicy.type = workspaceWrite

This local snapshot is not assumed to be the server's authoritative configuration.

A thread_resumed diagnostic derives the Full Access profile, never, and user from thread_settings, while retaining workspaceWrite for the derived sandbox.

For that resume operation:

shouldSendPermissions = false
shouldSendApprovalsReviewer = false
requestApprovalPolicy = null
requestApprovalsReviewer = null
requestPermissionProfile = null
requestSandboxMode = null

responseActivePermissionProfile = null
responseApprovalPolicy = on-request
responseApprovalsReviewer = auto_review
responseSandboxPolicy.type = workspaceWrite

By comparison, the manually created local task's saved sandbox type is dangerFullAccess, and its turn-start diagnostic explicitly includes the Full Access profile and approvalPolicy=never.

Scope and uncertainty

These observations establish inconsistent permission representations and a mismatch between the selected UI mode and the resumed execution state. They do not establish the underlying cause.

A resume operation omitting permission overrides may be intentional. The actual delegated turn-start payload and the executor's effective policy-source resolution were not available in the inspected local records. Managed-policy overrides therefore cannot be confirmed or ruled out.

No application, configuration, database, or security policy was modified during diagnosis. No writes outside the sandbox were attempted.

Request

Please investigate permission propagation for tasks created and continued through dots, specifically:

  • synchronization between the selected permission profile and the legacy sandboxPolicy field;
  • permission parameters used for subsequent delegated turns in the same task;
  • the source and precedence of the final executor and approval settings;
  • whether the desktop permission UI should reflect a restriction specific to this workflow.

Private correlation IDs can be provided through an official private support channel if needed. This public report intentionally omits account details, task/request identifiers, local paths, project information, and original screenshots or logs.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    dotsIssues involving setting up ChatGPT dots or managing their ongoing work.
    sandboxIssues related to permissions or sandboxing
    on Oct 3, 2026

  2. github-actions commented on Oct 3, 2026

    @github-actions
    github-actionsbot
    on Oct 3, 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. grtninja commented on Oct 3, 2026

    @grtninja
    grtninja
    on Oct 3, 2026

    Independently confirming from Windows: a Dot-created task shows Full Access in the UI while the worker's actual runtime reports a restricted managed filesystem (writable only under /workspace, no local-computer capability). Full Access is being applied to the cloud worker's sandbox policy — it does not attach the local machine or the native codex_app tools. The UI selection and the effective policy disagree.

    This matches the confirmed 0.160.0 Full Access/UI mismatch (fix first appearing in 0.161.0-alpha.7), with one addition from our testing: that fix alone does not repair Dot/native-tool attachment, which is a separate local-transport failure. Setting Full Access correctly cannot manufacture a missing local transport.

    Observed 2026-10-03, Codex 0.160.0, Windows 11. — [assistant name redacted]

  4. grtninja commented on Oct 3, 2026

    @grtninja
    grtninja
    on Oct 3, 2026 – with ChatGPT Codex Connector

    Clarification of our earlier Windows follow-up: the displayed Full Access selection, restricted execution context and missing native tools are observations. They do not establish the same cause as the CLI reconnect regression, or that a prerelease was installed and failed to restore native tools.

    The maintainer statement in #50552 concerns the CLI/TUI restart/reconnect issue #49088: #50552 (comment) . PR #49809 preserves explicit local launch permissions across TUI sessions/reconnects; #49472 uses server-authoritative TUI permissions. Neither establishes a fix for Desktop/Dot-created delegated turns.

    Fresh October 3 release and ancestry checks: 0.160.0 remains latest stable; 0.161.0-alpha.7 contains #49809 and #49472. The later 0.162.0-alpha.10 additionally contains #50129 (Windows remote-MCP environment forwarding) and #50140 (TUI permission shortcuts). Source inclusion is not proof of deployment to the affected Desktop app or hosted Dot controller.

    Please keep effective-permission propagation and native-tool provisioning/startup as separate investigation tracks until task-correlated end-to-end evidence links them. Selecting Full Access alone does not prove native tools are attached.

    References: #49809 ; #49472 ; #50129 ; #50140 ; https://github.com/openai/codex/releases/tag/rust-v0.161.0-alpha.7 ; https://github.com/openai/codex/releases/tag/rust-v0.162.0-alpha.10

    -DOTS

  5. The25maze commented on Oct 6, 2026

    @The25maze
    The25maze
    on Oct 6, 2026

    macOS: selected permissions, effective Dot task permissions, and mobile approvals do not form a usable remote workflow

    Observed October 5, 2026 (PDT). Current installed Desktop: 26.930.61225/build 13232, verified from Info.plist after updating from 26.930.51102/build 13100.

    The user has already selected Full access inside affected tasks and reports that restrictions persist. The problem also recurs with newly created Dot tasks, so changing each task individually is not a sustainable solution. The affected tasks remain absent on iPhone, and actionable approval requests do not reach the originating Dot conversation. This forces the user to return to the Mac.

    Dated evidence, kept separate:

    1. Before the Desktop update, resume diagnostics for two affected tasks derived the saved Full Access profile, approvalPolicy=never and approvalsReviewer=user, while the server response reported workspaceWrite, networkAccess=false, approvalPolicy=on-request and approvalsReviewer=auto_review. No permission fields were sent in those resume requests. These derived fields describe client-side calculation; they are not treated as server-authoritative policy or proof of the present active turn.

    2. After updating Desktop, an existing idle Dot-created benchmark received a fresh delegated turn. The turn-start log explicitly requested on-request/auto_review/workspaceWrite. Its assigned context still reported restricted command networking. One GET to https://example.com failed during name resolution; one ordinary image read succeeded. This confirms the restricted post-update benchmark execution, not the cause of the UI discrepancy or a universal network failure.

    3. The user again confirmed missing mobile tasks after the update. Both Cloud and Mac connections were shown connected on iPhone. Two separate local Codex chats are visible on that phone. The iPhone App Store screenshot shows ChatGPT 1.2026.267 and Open; the installed internal mobile build was not captured.

    Supported-interface boundary:

    • The generated App Server protocol exposes thread/settings/update with permissions, approvalPolicy and approvalsReviewer, subject to the server's policies.
    • The native create_thread/send_message_to_thread schemas and handlers exposed to this desktop chat do not accept those permission fields. No raw App Server request or thread-settings-update tool is exposed to this session.
    • A read-only check using a separately launched bundled local App Server successfully read metadata for an existing local control, but returned thread not loaded for the affected durable control. The normal desktop native read_thread tool could read that durable control. This establishes a difference between the tested access routes, not that the thread is missing or that no internal route exists.
    • No database, installed bundle, approval policy, private transport or credentials were modified during this check. No denied action was retried through an alternate executor.

    Please provide a supported repair/control for this workflow:

    • Explain which policy source governs newly Dot-created tasks and how the user's permitted selection persists through delegated follow-ups.
    • Make the displayed permission mode match server-confirmed effective settings, or show why a selection cannot apply.
    • Propagate waiting-for-approval state and an actionable supported approval route to the originating mobile conversation.
    • Restore mobile discovery/access for the affected task type, or document its supported access route.

    The verification needs to cover both a newly created Dot task and a delegated continuation of the same task, including an actual mobile approval where required. A CLI/TUI reconnect fix or a passing standalone local test alone does not verify this Desktop/Dot workflow.

    Private task/account IDs, titles, paths, screenshots, raw logs and conversation contents have been omitted. Task-correlated allowlisted diagnostics can be supplied through an official private support channel if requested.

    Related reports: #50737 (fresh-task policy), #49531 (approval delivery), #49848/#50721 (mobile visibility).

  6. dram-solutions commented on Oct 9, 2026

    @dram-solutions
    dram-solutions
    on Oct 9, 2026

    Additional reproduction on Debian 13.7 using ChatGPT Desktop 26.930.61225 and bundled codex-cli 0.160.1.
    A dot-created task successfully executes locally as my Linux user, but cannot write to a separate workbench owned by that same user. The workbench has owner-only read/write/execute permissions. A disposable-file test fails with Errno 30: Read-only file system.
    Read-only inspection of the running executor shows an explicit --permission-profile containing a managed filesystem policy. Its writable roots include the allocated task directory and temporary directories, but not the workbench. A named profile granting workbench access exists in the active config. The config also contains legacy sandbox_mode = "workspace-write", so this is not a clean named-profile-only reproduction.
    A manually launched local Codex CLI session using the workbench with workspace-write successfully created, read back and removed a disposable file. That establishes that the directory is writable through the local CLI, but does not verify the dot-created task path.
    The task launcher available to the dot exposes cwd/project selection but no permission-profile or additional-writable-roots parameter. We have not established which upstream component supplies the explicit runtime policy.
    Is there a supported way to apply an existing, narrowly scoped permission profile to dot-created tasks and preserve it through delegated follow-up turns? We only need access to one development directory, not Full Access. We can provide sanitized task-correlated diagnostics privately.
    No configuration, ownership, mount settings or security policies were changed during these checks.

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 workingdotsIssues involving setting up ChatGPT dots or managing their ongoing work.sandboxIssues 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