Repository navigation
Cross-task delegated turns ignore visible Full Access until direct user input #32165
Description
Environment
- Codex Desktop: 26.707.31428 (build 5059)
- Bundled/local Codex CLI: 0.144.1
- macOS: 26.5.2
- Target task visibly configured as Full access
Summary
A turn delivered to an existing task through cross-task messaging can run with a managed/restricted network policy even though the target task's composer displays Full access.
Submitting a direct user message in the same target task immediately fixes the execution boundary: the same localhost connection then succeeds.
This appears to be a permission-context propagation gap specific to cross-task delegated turns, similar to the automation and Goal continuation issues listed below.
Steps to reproduce
- Open task B in Codex Desktop and select Full access.
- Start a harmless localhost HTTP listener.
- From task A, send a message to task B using Codex cross-task messaging.
- In task B, observe the incoming bubble labeled "Sent by Codex from another task".
- Have that delegated turn connect to the localhost listener using both
curland Pythonsocket.create_connection. - Observe:
lsofcan see the listener.curlcannot connect.- Python raises
PermissionError: [Errno 1] Operation not permitted.
- Without changing the visible permission selector, submit a direct user message in task B.
- Repeat the same localhost connection.
- The connection succeeds.
Expected behavior
A cross-task delegated turn should inherit the target task's current effective Full Access policy.
If delegated turns are intentionally restricted, the UI should display the delegated turn's effective permission policy instead of continuing to show Full access.
Actual behavior
- Cross-task delegated turn: managed/restricted network execution despite the target composer showing Full access.
- Direct user-submitted turn in the same task: Full Access takes effect and the same localhost operation succeeds.
The visible permission state and effective turn execution state therefore disagree.
Impact
- Cross-task orchestration can silently fail on localhost services, development servers, Docker-backed workflows, MCP servers, and other network-dependent tools.
- The assistant may incorrectly diagnose service, DNS, authentication, or application failures when the actual cause is stale/restricted turn permissions.
- The only observed recovery is manual user intervention in the target task, defeating unattended orchestration.
Related issues
- Desktop automations silently fall back to workspace-write sandbox regardless of app configuration #15310 — background automation turns omit the desktop Full Access override until manual chat interaction
- Goal auto-continuations can downgrade Full Access threads to read-only/on-request while UI still shows Full Access #24300 — Goal continuations can run as managed/read-only while the UI shows Full Access
- Windows Desktop: new threads/handoffs persist as on-request/workspaceWrite instead of inheriting visible Full Access state #25810 — new threads and handoffs may not inherit visible Full Access
The distinguishing trigger here is an existing task receiving a cross-task delegated message, followed by a direct user message in that same task.
Activity
samtuke commentedon Oct 15, 2026
We observed a closely matching delegated-task permission mismatch on macOS on 15 October. This is evidence from the effective runtime records, rather than an inference from the agent asking a question.
Environment: installed Desktop 26.1007.30912 (build 20156), bundled runtime 0.162.0-alpha.17.2, macOS 27.0.1 arm64. The local configuration inspected during this investigation contains approval_policy="never" and sandbox_mode="danger-full-access".
Sanitized timeline, all UTC:
This extends the report to newly created delegated chats, as well as existing-task continuations. The direct-user turn followed the recorded Full Access settings update, so we cannot separate the effect of the settings update from direct input. We did not reproduce the localhost test or establish which client path selected the child's initial restricted profile.
Expected: delegated execution should honor the intended permission selection, and the UI should expose the actual executing profile and the source of any override. No raw rollout, credentials, private paths, or project details are included here.