Remote Control created-thread card loses source host and opens child task on controller-local host

Summary

A task running on an enrolled Remote Control host can create a child task in a project local to that host. The creation succeeds and the child runs normally, but the created-thread card shown on the controller loses the source host and routes the child thread ID to the controller's local app-server.

This is not task loss or an Iris execution failure. Cross-host task listing later resolves the same thread ID to the Iris Remote Control environment, and an explicit read through that host succeeds.

Environment

• Controller: macOS 27.0 (26A5388g)
• Codex Desktop: 26.727.51351, build 6119
• Codex runtime: 150.0.7871.182
• Producer: Iris, native Windows, enrolled through Remote Control
• Affected child thread: 019fce28-1fc8-77a0-8872-6a28efd8c28c

Reproduction

1. Open a Codex task running on a Remote Control host.
2. From that task, invoke create_thread for a project local to the remote host.
3. Observe the successful result from the producer:

``json
{
"threadId": "019fce28-1fc8-77a0-8872-6a28efd8c28c",
"hostId": "local"
}
``

Here, local correctly means local to Iris.

1. On the Mac controller, click the resulting created-thread card.
2. The child fails to load / is looked up on the controller-local app-server.
3. List tasks across connected hosts.
4. The same thread is returned with an owner equivalent to:

``text
remote-control:<iris-environment-id>
``

1. Reading the thread through that resolved host succeeds. The child executed and persisted normally on Iris.

Actual behavior

The producer-relative host alias local crosses the Remote Control boundary without being rebased to the controller-visible Iris host. The created-thread card then navigates using only the bare thread ID and treats it as controller-local.

Expected behavior

A child task created on a Remote Control host should open immediately from the controller.

Codex should either:

• translate producer-relative local to the producer's controller-visible remote-control:<environment-id> identity and preserve it through the card/navigation path; or
• resolve the globally unique thread ID across connected hosts, using the source task's host as the primary context, before navigation.

Another host's literal local must never be interpreted as controller-local.

Diagnostic evidence

Inspection of the installed Desktop bundle indicates two compounding seams:

1. The create_thread adapter appends its process-relative destination host to the result. No producer-to-controller rebase occurs when the producer is a Remote Control Desktop instance.
2. The created-thread directive/card schema retains threadId or clientThreadId, but not hostId. Card navigation then uses a local route based only on the thread ID.

By contrast, the later cross-host list/read path enumerates connected app-server managers and resolves the canonical Remote Control host, which explains why the same task becomes readable after discovery/hydration.

The relevant Desktop adapter/card implementation does not appear to be present in the public repository. The public app-server code exposes Remote Control environmentId, but controller host association is a Desktop-layer concern.

Suggested regression test

From a controller:

1. Execute create_thread on a Remote Control host using a project local to that host.
2. Return the result to the controller.
3. Before any later catalog synchronization, click the created-thread card.
4. Assert that the returned/associated host is the canonical Remote Control environment and that the child opens successfully.
5. Assert that the producer's local alias is never routed to the controller-local app-server.

Related issues

• #33359 — closest known mechanism: remote thread IDs are hydrated against the local app-server until cross-host lookup provides the correct host
• #32524 — selected remote host routed as hostId=local
• #36748 — one Remote Control task surfaces with inconsistent remote-control and local bindings
• #25092 — remote conversations disappear locally while remaining intact remotely