Skip to content

fix(ssh): orca open-url on a managed SSH host opens the page on the desktop through the browser bridge - #30849

Merged
nwparker merged 2 commits into
mainfrom
nwparker/orcad-open-url-bridge
Oct 19, 2026
Merged

nwparker merged 2 commits into
mainfrom
nwparker/orcad-open-url-bridge

Conversation

@nwparker

@nwparker nwparker commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor
Files Added Deleted Net
Test 3 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​126 $\color{#cf222e}{\Huge{\mathbf{−}}}$​2 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​124
Prod 2 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​19 $\color{#cf222e}{\Huge{\mathbf{−}}}$​7 $\color{#1a7f37}{\Huge{\mathbf{+}}}$​12

ELI5

When an agent works on a remote machine that Orca manages over SSH, it can run orca open-url to show the user a web page. Until now that command always failed on those machines, and the error told the user to "bring the desktop back online" even though the desktop was online. Now the page opens in the desktop's Orca browser, just as orca tab create --url already does.

What Changed

Before: on a managed SSH host, orca open-url --url https://… failed every time:

  • With the host's browser-control switch on (the default), it said browser.openUrl is not available from an SSH host.
  • With the switch off, or no desktop connected, it returned browser_host_unavailable, which says the desktop hosting the page is offline and to bring it back. Retrying could never work, because a managed SSH desktop never hosts that host's pages.

After:

  • With the switch on, the page opens as a tab in the host's workspace on the desktop. It loads through the host, exactly like orca tab create --url.
  • With the switch off, or no desktop sharing its browser, open-url gives the same error as every other bridged browser command. That error names the "Allow this host's orca CLI to control Orca" setting.

Mechanism: the decision happens in the host-side route that picks which of the host CLI's browser commands go to the desktop (desktop-browser-bridge-route.ts). It now sends browser.openUrl to the desktop as a browser.tabCreate request carrying only { url, worktree }. Before forwarding, it checks on the host that the URL is http(s), using the check open-url already had, now pulled out as assertClientOpenableUrl. On the desktop, the request is an ordinary tabCreate. It passes through the same checks as one: the per-host switch, the routed-browsing check, workspace scoping, URL validation, the rule that a host cannot pick focus or a profile, the audit log, and the cancel/revoke handling from #30630.

Why

browser.tabCreate is already on the bridge's allowlist. Open-url is the same operation with an http(s)-only URL, so it adds no new way to reach the desktop. browser.openUrl deliberately stays off the desktop's allowlist, so its allowlist test is unchanged.

Mixed versions:

Alternatives considered:

  • Keep refusing and fix only the error text, pointing users at orca tab create --url. Rejected because open-url is equivalent, and the bridge already allows the equivalent command.

Two behaviours to note:

  • The desktop removes activate/navigation from any request a host forwards, so a page opened this way does not take focus. That's the existing rule that a host cannot steal the desktop's focus, and tab create --url behaves the same way.
  • If a desktop has attached the bridge and a different paired desktop also hosts this host's pages, open-url now goes to the bridge desktop. tab create already behaves this way. Without an attachment, the fix(orcad): orca open-url opens the page on the paired desktop #30782 path to the page-hosting desktop is unchanged.

Linked Issue

Follow-up to #30731 / #30782 (managed SSH case). No separate issue.

Visual Proof

N/A. This is a CLI/RPC routing change with no UI change. The e2e asserts that the desktop tab appears, and that its request reached the host-only fixture origin.

Testing

  • Automated tests added/updated, or explained why not below

  • I manually tested these changes locally

  • desktop-browser-bridge-dispatch.test.ts: four new cases. Open-url is forwarded as browser.tabCreate with the workspace pinned, and returns the desktop's browserPageId. A file:// open-url is refused on the host before it reaches the desktop. With no desktop attached and no local browser, the error names the setting. With a desktop hosting this host's pages and no bridge attached, open-url still goes the fix(orcad): orca open-url opens the page on the paired desktop #30782 way. The first three fail on main.

  • ssh-orcad-desktop-browser-bridge.spec.ts (Docker managed-orcad lane): the host's own orca open-url opens a desktop tab that loads through the host. With the setting off, open-url returns desktop_browser_bridge_unavailable naming the setting. Both assertions fail on main.

  • ssh-orcad-browser-capabilities.spec.ts: that call comes from a paired client, not the host's CLI, so browser_host_unavailable is still the correct answer there. I rewrote the misleading comment.

  • Locally: the folders around the changed files (src/main/runtime/{desktop-browser-bridge,browser,session-graph}, src/main/orcad, src/main/browser/desktop-browser-bridge), and every step of the static-analysis job, including typecheck and all ratchets. The only local failure was the known macOS /private/var tmpdir issue in orcad-forked-child-paths.test.ts, which this PR doesn't touch.

  • Live verification: not run on a real host. The end-to-end proof is the Docker managed-orcad e2e lane in CI.

Review

  • Codex (gpt-6.1-sol, high): no findings.
  • Opus: no blocking findings. It raised the two notes above (focus is not taken, and the bridge desktop wins over a different page-hosting desktop). Both are kept on purpose to match tab create.

Agent skill upstream boundary

  • Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Security: no new desktop-side method or parameter, and the desktop stays the trust boundary. SSH: the host keeps resolving its own selectors. Cross-platform: no platform-specific code. Mobile: unaffected.

Checklist

  • This PR is small and focused
  • I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
  • Before/after screenshots or videos attached for UI changes, or N/A with reason
  • Self-reviewed for correctness, security, and performance
  • Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
  • pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

@coderabbitai

coderabbitai Bot commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 1 minute.

Check out review usage here.

View limit details

Limit details: You’ve used all 10 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration
  • Configuration used: Repository UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 64c2f0cc-c8ec-4e81-83ae-655a8d7ebdfa
📥 Commits

Reviewing files that changed from the base of the PR and between 575d3b2 and 80907a4.

📒 Files selected for processing: 5
  • src/main/runtime/browser/browser-client-page-opening.ts
  • src/main/runtime/desktop-browser-bridge/desktop-browser-bridge-dispatch.test.ts
  • src/main/runtime/desktop-browser-bridge/desktop-browser-bridge-route.ts
  • tests/e2e/ssh-orcad-browser-capabilities.spec.ts
  • tests/e2e/ssh-orcad-desktop-browser-bridge.spec.ts
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@nwparker
nwparker merged commit da0db9f into main Oct 19, 2026
87 of 89 checks passed
Jinwoo-H added a commit that referenced this pull request Oct 20, 2026
…esktop again, not an SSH setting (#31120)

Every orcad turned on the SSH host browser bridge, so since open-url began going through it
(#30849) a user-started serve with no desktop refused with SSH-settings advice. Only a client's
managed launch enables the bridge now; a started server answers browser_host_unavailable (#30782).

Co-authored-by: E2E Test <e2e@test.local>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant