[macOS][Remote Control] create_thread silently downgrades Air-to-Mini child permission profile

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

• Current target-host Codex Desktop: 26.818.41509 (build 6962)
• Current target-host Codex CLI/runtime: 0.149.0
• Incident-time controller runtime recorded in the parent session: 0.149.0-alpha.4.3
• Incident-time target runtime recorded in the child session: 0.149.0-alpha.4.1

The controller's incident-time Desktop bundle version was not retained in the inspected session metadata.

What subscription do you have?

Not provided; not relevant to the local cross-host permission propagation behavior.

What platform is your computer?

Two Apple Silicon Macs running Codex Desktop on macOS:

• Controller: MacBook Air using Codex Remote Control
• Target: Mac Mini enrolled as a Remote Control host
• Current target OS: Darwin 25.6.0 arm64 arm / macOS 26.6.1 (25G76)

What issue are you seeing?

A full-access parent task on the MacBook Air creates a child task on the remote Mac Mini with the official create_thread tool. The child starts automatically, but the cross-host path silently substitutes a restricted permission profile.

The parent is recorded as:

approval_policy = never
sandbox_policy = danger-full-access
permission_profile = disabled

The same-host Air-to-Air child receives that profile. A Mini-local parent creating a Mini-local child also receives that profile. In contrast, the Air-to-Mini child starts as:

approval_policy = on-request
sandbox_policy = workspace-write
network_access = false
permission_profile = managed/restricted

The high-level create_thread call contains no permission, approval, sandbox, or access fields, and the tool schema exposed to the parent offers no such fields. The parent therefore cannot require the expected profile or inspect the destination's resolved profile before the child's first turn begins.

This caused an unattended implementation task to stop at a terminal approval dialog while installing already-planned workspace dependencies. The installation was the trigger, not the root cause: the controlled reproduction below proves that the permission discontinuity exists before any dependency install, network request, or repository mutation.

What steps can reproduce the bug?

1. On Mac A, configure a Codex Desktop parent task with:

   approval_policy = never
   sandbox_policy = danger-full-access
   permission_profile = disabled
   

2. Enroll Mac B as a Codex Remote Control host and save a local project on each Mac.

3. From the same parent turn on Mac A, call the official create_thread tool twice with the same prompt shape:

   • Child A targets the local project on Mac A.
   • Child B targets the project on remote Mac B with environment: { type: "local" }.

4. In each child, run only these harmless commands:

   /bin/pwd
   /usr/bin/printf 'CODEX_PERMISSION_PROBE\n'
   

5. Inspect each child's initial TurnInputRequest and first effective turn context.

Controlled result observed on 08/25/2026 at approximately 6:37 AM Pacific:

All probes completed without installing dependencies, using the network, or modifying a repository.

Relevant session IDs:

• Incident parent: 01a027c2-84e0-72b0-9fe2-29e4f82785a6
• Incident remote child: 01a036a5-6361-7e82-a6b7-41392bc4505e
• Controlled Air-to-Air child: 01a03923-e369-7170-b01b-f43a830e89e4
• Controlled Air-to-Mini child: 01a03923-f0e6-7833-b7ca-bf745ff12f18
• Controlled Mini-to-Mini child: 01a03923-5302-7821-b606-2469f6d590fc

What is the expected behavior?

Cross-host child creation should do one of the following before starting the child's first turn:

1. Preserve the explicitly active parent execution profile when that profile is valid on the destination; or
2. Let the caller pass a required permission/execution profile and fail atomically if the destination cannot honor it.

In every case, create_thread should return the destination's resolved approval policy, sandbox policy, network capability, and active permission profile. It must not report successful creation and start meaningful work when the effective destination profile differs silently from the requested or inherited profile.

Additional information

This appears to be a cross-host orchestration/app-server contract defect rather than a package-manager behavior or prompting mistake:

• The discontinuity is deterministic in a minimal no-network probe.
• Same-host child creation on both machines preserves full access.
• Only controller-to-remote child creation substitutes the restricted profile.
• The parent-side launch arguments and public tool schema contain no field that can express the requirement.
• The target receives explicit restricted ThreadSettingsOverrides, so the popup accurately reflects the child's actual policy; the UI prompt is a symptom, not the defect.

Related but not duplicate:

• #33282 reports same-host managed-worktree children losing the auto-reviewer setting on Windows.
• #29054 reports remote full-access approval prompts after reconnect.
• #25810 reports Windows new threads/handoffs persisting as on-request/workspaceWrite.

Requested correction:

• Add an explicit required execution profile to the cross-host create_thread request.
• Return the destination's fully resolved execution profile in the creation response.
• Refuse to auto-start the first turn when required and resolved profiles differ.
• Add a Mac-to-Mac Remote Control regression test comparing local and remote children.

A screenshot of the original approval dialog is available, but omitted here because the uncropped image contains unrelated task titles and account information. Sanitized raw log excerpts can be provided privately if requested.

Start at the cross-host create_thread request and response path, then trace how the destination resolves permission and execution settings before the first turn. Add the requested Mac-to-Mac Remote Control regression test using the local and remote child comparison. Done means the required profile is preserved or mismatches fail before work starts, and the resolved profile is returned.