[macOS][Remote SSH] Built-in browser unavailable with native-pipe untrusted-process-ancestry; local IAB and remote Chrome work #48786

What version of the Codex App are you using?

26.924.22138, build 11645 (installed macOS app).
Bundled/remote CLI reported 0.158.0-alpha.2.1.

What subscription do you have?

Not included in this public report.

What platform is your computer?

macOS 26.6.2 (25G83), Apple Silicon.
uname -mprs: Darwin 25.6.0 arm64 arm.

What issue are you seeing?

In a Desktop-managed Remote SSH task backed by a Mac, the built-in browser panel visibly loads pages and ambient browser context reaches the task, but the supported browser-control API cannot discover or select the IAB backend.

• cua.listBrowsers() returns only the Chrome extension.
• cua.createBrowserTab("iab", "https://example.com", {visible:true}) returns Browser is not available: iab.
• cua.getTab({url:"https://example.com/"}, {browser:"iab"}) also fails.
• Desktop logs at the corresponding discovery/selection calls report untrusted-process-ancestry.

Unlike reports where all browser tools are absent, this remote task has the unified Computer Use runtime, and Chrome extension browsing works. Native Computer Use with Chrome also works.

A separate desktop-local task on the same physical Mac successfully opened example.com in IAB, clicked Learn more, and reached IANA with the title Example Domains. This was a diagnostic comparison; moving production work to local projects is not an acceptable workaround.

The user reports that browser use previously worked while using remote projects, which are their normal workflow. The last known-good version and whether the earlier successful path was specifically IAB versus Chrome have not been established. Please investigate a possible regression or configuration/connection mismatch rather than assuming that remote browser use was never supported.

What steps can reproduce the bug?

1. Run the macOS desktop app and use a saved Remote SSH project backed by a Mac with the app and bundled runtime installed.
2. Continue an ordinary SSH-backed task. In our reproduction, the desktop app is also running on the execution Mac and its panel for the affected task is visible there.
3. Open example.com in that task's built-in browser panel.
4. Ask the task to use the built-in browser, click Learn more, and report the resulting title.
5. Observe that supported browser discovery lists Chrome only and selecting iab fails.
6. Check desktop logs at the same instant: native browser-pipe peer authorization rejects the connection.
7. As a comparison only, run the same navigation in a new desktop-local task on that Mac; it succeeds.

The current failure has been reproduced repeatedly in this existing remote task. A fresh remote-task reproduction has not yet been established.

What is the expected behavior?

The remote task should be able to control its authorized built-in browser while shell/filesystem work remains on the remote host, preserving session ownership and security checks. If this exact topology requires different supported setup, provide the concrete configuration/recovery procedure and an actionable error.

Do not require switching project work to local tasks or disabling native peer authorization.

Additional information

Sanitized, time-correlated evidence from the most recent discovery request:

2026-09-27T21:08:31.879Z warning [browser-use-native-pipe-server] browser-use native pipe rejected socket peer reason=untrusted-process-ancestry

This appeared three times at that timestamp. Earlier IAB selection/discovery requests also coincided with the same rejection.

Process topology:

• The successful local task's runtime descends from the desktop-owned app-server.
• The affected remote task's runtime descends from the SSH app-server, which is detached with parent PID 1.
• Both servers use the app-bundled Codex executable.
• The running desktop executable, remote Codex executable and loaded native browser peer-authorizer match the installed files by inode, so those processes are not retaining replaced binaries from an earlier installation.
• The installed desktop, Codex, node and node_repl executables report OpenAI code-signing authority.

We have identified the failing authorization boundary, not the full root cause or the native validator's intended ancestry contract.

Earlier stale per-thread website denials were removed with user authorization, restoring Chrome access. IAB discovery still fails. Browser-runtime reset did not repair it. Full CDP remains disabled. No executable patch, security-check bypass, alternate transport, or project migration was performed. No shared-service restart was attempted during this final isolation pass because other work was active.

Related reports reviewed:

• Codex Desktop Remote SSH: in-app browser sidebar works but @browser is unavailable in remote thread #22844 — same Remote SSH visible-panel / unavailable-IAB symptom, including a macOS reproduction.
• macOS Desktop: Browser/node_repl tools are not provisioned to Remote SSH tasks #34263 — remote browser runtime provisioning; our runtime is present and Chrome works.
• Remote SSH IAB route appears only after opening the same thread in the remote Linux GUI #44782 — remote-host GUI route registration; our affected task's host-side panel is already open.
• [Desktop][Browser Use] No ChatGPT browser route prevents Chrome and built-in browser tab discovery #47270 — broader routing failures; a comment on build 11645 also reports native-pipe ancestry rejection.

Please determine whether this is the same underlying defect or a distinct macOS peer-authorization incompatibility with the SSH app-server lifecycle. We can provide further targeted diagnostics privately. This report intentionally omits private project names, account data, hostnames, task identifiers, browser profile data and full logs.