Remote Control-created target thread hits Chrome Browser Use enterprise-policy block while target-local thread passes #30623

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

Target Mac:

Codex app: 26.623.70822, build 4559
Codex CLI: 0.142.4
Chrome plugin/browser-client bundle observed in plugin cache: 26.623.70822

What subscription do you have?

GPT Pro

What platform is your computer?

Target Mac:

macOS 26.5.2 (25F84)
Darwin arm64

Topology:

Controller Mac: Codex Desktop used as the remote-control surface
Target Mac: Codex Desktop host with Chrome plugin/extension installed and connected
Chrome profile on target: normal user Chrome profile with Codex Chrome extension connected
Codex Chrome extension id: hehggadaopoacecdllhhajmbjkdcmajg

What issue are you seeing?

A Chrome Browser Use task succeeds when the thread is created directly from the target Mac's Codex Desktop UI, but the same task fails when a new target-host thread is initiated from another Mac's Codex Desktop Remote Control connection.

This does not look like a blanket target-host Chrome extension failure, Chrome profile failure, or HTTPS/browser-use limitation. The target host can use Chrome Browser Use successfully when the thread is created locally on that target host.

Working target-local thread:

thread_id: 019f150f-dcad-7783-92a1-02c4de1fbfee
created: directly from target Mac Codex Desktop UI via remote desktop/RDP
result: pass

That thread successfully:

• connected to the Chrome extension runtime;
• opened https://example.com;
• read DOM/page state;
• found the visible Learn more link;
• clicked it;
• verified navigation to https://www.iana.org/help/example-domains.

Working child thread created by that target-local thread:

thread_id: 019f1517-b93a-78d1-8224-913a105e84bf
created: by the working target-local thread
public metadata: thread_source: subagent
result: pass

Failing remote-control-created target thread:

thread_id: 019f150e-5da1-7e53-9eb3-9c680aa9cccf
created: from controller Mac Codex Desktop, targeting the same target Mac through Remote Control
result: fail

In the failing thread, Chrome runtime connection succeeds, but Browser Use fails before page interaction at tab.goto("https://example.com"):

Browser use cannot access https://example.com because enterprise network policy blocks it.

The public session metadata did not explain the difference. The working target-local user thread and failing remote-control-created target user thread both appeared as user-created Codex Desktop threads in the same target project. The child thread that worked was marked thread_source: subagent.

This suggests hidden effective Browser Use policy/runtime state differs based on the Remote Control invocation path.

What steps can reproduce the bug?

1. On a target Mac with Codex Desktop, install/enable the Chrome plugin and confirm the Codex Chrome extension shows connected.
2. From the target Mac's own Codex Desktop UI, create a new thread and run a Chrome-only smoke test against https://example.com:
   • initialize the Chrome extension browser runtime;
   • create a disposable tab;
   • tab.goto("https://example.com");
   • take a DOM snapshot or evaluate page state;
   • click the Learn more link;
   • verify navigation to IANA;
   • finalize/clean up tabs.
3. Confirm that target-local thread passes.
4. From a different Mac's Codex Desktop app, use Remote Control to create a new thread on that same target Mac and same project.
5. Run the same Chrome-only smoke test.
6. Observe that Chrome runtime connects, but navigation/content access fails with the enterprise-policy error.
7. Optionally, from the working target-local thread, create a child/follow-up thread and run the same smoke test. In this test, the child thread also passed.

What is the expected behavior?

Remote Control-created threads should use the connected target host's plugins, browser setup, permissions, local tools, and Browser Use policy state. If Chrome Browser Use works in a target-local thread on the same target Mac, the same Chrome Browser Use smoke test should also work in a Remote Control-created thread targeting that Mac.

This matches the Remote Connections docs expectation that the connected host provides plugins, browser access, local tools, permissions, and configuration for remote sessions.

Actual behavior

The target-local thread and target-created child thread can use Chrome Browser Use normally.

The controller-created Remote Control target thread can connect to Chrome but is denied at page navigation/content access with:

Browser use cannot access https://example.com because enterprise network policy blocks it.

Additional information

Related issues found before filing, but none looked like an exact duplicate:

• Remote Control: target node_repl launches with controller CODEX_HOME env despite correct target config #26560: Remote Control target node_repl launches with controller CODEX_HOME; same Remote Control identity/state class, but different failure mode. In this report, node_repl/Chrome runtime connects and fails later at Browser Use policy.
• Mobile-started remote Codex thread cannot use Chrome plugin: browser-client is not trusted #23302: mobile-started remote thread cannot use Chrome plugin because browser-client is not trusted; similar remote-started boundary, different client and error.
• Browser Use node_repl/js availability diverges by thread in Codex Desktop #21301: Browser Use node_repl/js availability diverges by thread; similar per-thread divergence theme, different symptom.
• Codex Chrome Extension connected but page content access is blocked by enterprise network policy #27160 and Windows Codex App: Browser Use blocked by enterprise network policy even for example.com #24814: same enterprise-policy wording, but generic/Windows-focused. This report differs because the same target Mac passes or fails depending on how the target-host thread is initiated.

Practical current workaround:

For Chrome-dependent work on the target Mac, create an orchestrator thread directly from the target Mac's Codex Desktop UI, then create follow-up threads from that known-good target-local thread. Avoid initiating Chrome-dependent target-host threads from the controller Mac's Remote Control surface until fixed.