Repository navigation
fix(ssh): orca open-url on a managed SSH host opens the page on the desktop through the browser bridge - #30849
Merged
Merged
Conversation
…esktop through the browser bridge
Contributor
|
Warning Review limit reachedYou'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. View limit details
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. Comment |
9 tasks done
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ELI5
When an agent works on a remote machine that Orca manages over SSH, it can run
orca open-urlto 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 asorca tab create --urlalready does.What Changed
Before: on a managed SSH host,
orca open-url --url https://…failed every time:browser.openUrl is not available from an SSH host.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:
orca tab create --url.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 sendsbrowser.openUrlto the desktop as abrowser.tabCreaterequest 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 asassertClientOpenableUrl. On the desktop, the request is an ordinarytabCreate. 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.tabCreateis 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.openUrldeliberately stays off the desktop's allowlist, so its allowlist test is unchanged.Mixed versions:
browser.tabCreatesince the bridge shipped (fix(ssh): agents on a managed SSH host can drive the desktop Orca browser again, behind the per-host switch #29384). Addingbrowser.openUrlto the allowlist instead would have been worse: an older desktop rejects a request whose method it doesn't know, and it can drop its whole bridge attachment when that happens. That would need a new capability flag.Alternatives considered:
orca tab create --url. Rejected because open-url is equivalent, and the bridge already allows the equivalent command.Two behaviours to note:
activate/navigationfrom 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, andtab create --urlbehaves the same way.tab createalready 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 asbrowser.tabCreatewith the workspace pinned, and returns the desktop'sbrowserPageId. Afile://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 ownorca open-urlopens a desktop tab that loads through the host. With the setting off, open-url returnsdesktop_browser_bridge_unavailablenaming 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, sobrowser_host_unavailableis 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/vartmpdir issue inorcad-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
gpt-6.1-sol, high): no findings.tab create.Agent skill upstream boundary
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
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)