Cross-task delegated turns ignore visible Full Access until direct user input

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

1. Open task B in Codex Desktop and select Full access.
2. Start a harmless localhost HTTP listener.
3. From task A, send a message to task B using Codex cross-task messaging.
4. In task B, observe the incoming bubble labeled "Sent by Codex from another task".
5. Have that delegated turn connect to the localhost listener using both curl and Python socket.create_connection.
6. Observe:

• lsof can see the listener.
• curl cannot connect.
• Python raises PermissionError: [Errno 1] Operation not permitted.

1. Without changing the visible permission selector, submit a direct user message in task B.
2. Repeat the same localhost connection.
3. 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

• #15310 — background automation turns omit the desktop Full Access override until manual chat interaction
• #24300 — Goal continuations can run as managed/read-only while the UI shows Full Access
• #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.