desktop_open_url cuts the URL at the first & (every OAuth link breaks)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 1mo ago ·closed by John Lauer

Reproduced on winvm with ab 2.1.132 (2026-09-19): desktop_open_url {url: <Google OAuth URL with access_type=offline&client_id=...&redirect_uri=...>} opened Edge on accounts.google.com/signin/oauth/error?authError=... which decodes to invalid_request, Required parameter is missing. Only the part before the first & reached the browser, so response_type and redirect_uri were dropped. The same URL typed into the address bar works. Looks like the verb hands the URL to a shell/start without quoting. Fix: quote the URL (or use ShellExecute with the full string) and add a test that a URL with & and = arrives intact. Hydrogen's AI sign-in relies on this verb path for Antigravity, Claude and Codex links.

1 Reply

John Lauer · 1mo ago

Fixed in insiders 2.1.136. Your diagnosis was exactly right.

Cause. desktop_open_url (and the GUI's own external-link opener) ran cmd /c start "" <url>. cmd treats & as a command separator, and Rust's Windows argument quoting only wraps arguments that contain spaces, so a URL with no spaces reached cmd unquoted and everything from the first & on was executed as a second command instead of being part of the URL. That is why response_type and redirect_uri never arrived.

Fix. Both paths now call ShellExecuteW("open", url) directly: no shell, nothing parses the string, and no console is spawned. One validator (open_url_target: scheme allowlist, no rewriting) is unit-tested to return a URL with &, = and %2F byte-identical.

Proof (arav-rog; a loopback HttpListener records the raw request line the browser sends; desktop_open_url with six &-separated params pointed at it):

URL: http://127.0.0.1:18204/cb?access_type=offline&client_id=abc.apps&redirect_uri=http%3A%2F%2F127.0.0.1%3A8910%2Fcb&response_type=code&scope=a%20b&state=xyz

2.1.135 (before): listener saw  GOT /cb?access_type=offline
2.1.136 (after):  listener saw  GOT /cb?access_type=offline&client_id=abc.apps&redirect_uri=http%3A%2F%2F127.0.0.1%3A8910%2Fcb&response_type=code&scope=a%20b&state=xyz   (byte-identical)

Hydrogen: nothing to change on your side; the same verb call works. If you open links through open_external_url-style Tauri commands of your own, check for the same cmd /c start pattern.

John Lauer closed this · 1mo ago