Repository navigation
[Bug]: Agents on SSH hosts can no longer drive the desktop Orca browser in 1.4.225 (worked via relay in 1.4.223) #29145
Description
Operating system
macOS (arm64 desktop client). SSH host: Ubuntu 26.04 arm64 VM (Docker sandbox), reached over SSH on 127.0.0.1.
Orca version
Broken: 1.4.225 (managed server orcad 0.1.0+2628c46c42a8). Works: 1.4.223 (relay 0.1.0+0d9e2827fa5f).
Details
Short summary
Up to 1.4.223, an agent in a terminal on an SSH host could drive the desktop's built-in Orca browser through the relay CLI (~/.orca-relay/bin/orca tab create, snapshot, click, …) once "Allow this host's orca CLI to control Orca" was on. Since the host moves to a managed Orca server (#24863), the orca CLI on the host talks to the host's own orcad, and every browser command returns browser_unavailable: Browser automation is unavailable on this host. There is no longer a way for an agent on an SSH host to use the desktop's (signed-in) browser.
This matters for sandboxed setups: the whole point of running agents in an isolated VM is that the VM has no credentials, while the desktop browser is already signed in (e.g. GitHub org SSO, private GitHub Pages). A headless browser inside the VM (ORCA_BROWSER_EXECUTABLE, once #28727 is fixed) does not replace this: it is not signed in and goes through the VM's network egress.
Steps to reproduce
- Orca 1.4.225 on macOS. Add a fresh Linux SSH host (no open terminals), turn on "Allow this host's orca CLI to control Orca", connect. Orca moves it to a managed server.
- In a terminal on that host:
orca status --json→target.kind: "local",installMode: "unsupported-headless-serve". orca tab list --json/orca tab create --url https://example.com --json.
Actual
{"ok":false,"error":{"code":"browser_unavailable","message":"Browser automation is unavailable on this host."}}. orca host list on the host shows only the host itself. Running orca tab create --environment <host> from the desktop gives the same error. Reconnecting, re-adding the host, or a brand-new VM doesn't change anything.
Expected
With the per-host switch on, the host's orca CLI can drive the desktop's browser, as it could through the relay. Per src/main/runtime/rpc/rpc-method-permission.ts, browser methods are in the workspace tier, which the switch grants (#26483); desktop-control only covers orca computer. So this seems to be lost routing rather than an intended permission change.
Verified workaround
Downgrade the desktop to 1.4.223. The same host reconnects over the relay, and ~/.orca-relay/bin/orca tab create / snapshot work again. Dispatching workers through the SSH host also works.
Related
- Phase 3: every SSH host runs a managed Orca server (orcad), replacing the relay, and orca serve runs on it #24863: managed server replaces the relay
- Phase 3.5: fix the top SSH/remote issues at the root cause #26483: SSH CLI guest permissions (browser =
workspacetier) - [Bug]: Terminal links on managed Orca server (SSH) hosts no longer offer Orca Browser — only System Browser (regression since 1.4.225) #29077: Orca Browser no longer offered for terminal links on managed SSH hosts
- [Bug]: Every built-in browser command fails on SSH hosts: "Unknown browser command" from orcad's headless provider #28727 / fix(orcad): forward headless browser commands through startup #28747: headless browser commands fail on managed SSH hosts
- feat(browser): option to route agent browser work to the Orca browser #28180: route agent browser work to the Orca browser
Ask
Either route browser RPCs from a managed host's CLI to the desktop browser (client-hosted pages) when the per-host switch is on, or document the supported way for an agent on an SSH host to use the desktop browser.
Activity
[-][Bug]: Agents on SSH hosts can no longer drive the desktop Orca browser after the managed-server move (worked via relay ≤1.4.223)[/-][+][Bug]: Agents on SSH hosts can no longer drive the desktop Orca browser in 1.4.225 (worked via relay in 1.4.223)[/+]edilsonborges commentedon Oct 15, 2026
Same here. Desktop: Orca 1.4.224 on Linux, online with the workspace open. SSH host: Linux, moved to a managed server (orcad 0.1.0+15ec2904eb00, CLI 1.4.224). Per-host CLI switch: on.
On the host, orca tab create, tab list and snapshot return browser_unavailable, even with a tab opened by hand on the desktop in the same workspace. The browser guide says a client-hosted page only needs the desktop online, and an offline desktop would give browser_host_unavailable, so the request never seems to reach the client-host path.
From the shipped orcad-server.js (minified names from this build), as far as I can tell:
Side note: desktopWindowStatus "blocked" is hardcoded in orcad, and the ORCA_BROWSER_EXECUTABLE hint in degradations is about the headless path, so neither is related.
AmethystLiang commentedon Oct 15, 2026
Thanks for reporting. Looking into it
nwparker commentedon Oct 16, 2026
Root cause, confirmed on current
main:orcaCLI ran on the desktop. The relay forwarded each invocation (orca.cliover the SSH mux) to the desktop runtime and tagged it with the host'sallowRemoteCliControlsetting. refactor(ssh): connect fails for hosts orcad can't serve; remove the relay client path #27214 (ff27338) removed that path, and nothing replaced it. Now the host's CLI talks only to the host's own orcad.allowRemoteCliControlnow has no effect. It is stored, shown in SSH host settings and passed throughssh.*RPCs, but nothing reads it. This affects everything the switch used to allow, not only the browser.browser.clientHost.*lease, and the desktop never attaches to orcad: orcad does not advertisebrowser.clientHost.v1, and the renderer only uses client hosting when the server advertisesbrowser.screencast.v1. On a managed SSH host, the desktop's browser tabs are desktop tabs whose traffic goes over SSH (Keep new browser tabs on SSH routing after managed conversion #26570). orcad has no record of them.Two ways to restore it, under discussion:
browser.*calls through it, and the desktop runs them on its own tabs for that workspace. orcad's worktree ids already match the desktop's. This brings back the 1.4.223 behavior and the signed-in desktop browser.Either way, this adds a new security-sensitive surface (a remote host driving a signed-in desktop browser), and older and newer desktops and hosts have to keep working together. It will get its own design review rather than a quick patch.
Related fix: #28727, where every headless command failed with "Unknown browser command", is fixed by #29250.