fix(mcp): Windows .dxt sign-in browser now opens reliably (product#3839) - #139
Merged
Merged
Conversation
On Windows, openInBrowser resolved the moment cmd.exe was CREATED — before its `start` builtin actually handed the URL to the browser. A silent no-op (no default-browser association / a locked-down shell / AppLocker) went undetected: nothing opened yet the flow reported success and told the user "a browser may have opened." Windows now waits (bounded) for each launcher's exit code, treats a non-zero exit as failure, and falls through to shell-free launchers — rundll32 url.dll,FileProtocolHandler (Explorer's ShellExecute path, honest exit code) then PowerShell Start-Process. When all fail, browserOpenFailedAtBootstrap is set and the AUTH_REQUIRED envelope honestly says the browser couldn't open, with the clickable sign-in link. macOS/Linux keep resolve-on-spawn (the #3805 headless-hang fix). The #3801 &-quoting cmd candidate is unchanged, tried first. Shutdown browser-open wait 1.5s -> 3s for the multi-launcher walk. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The PowerShell Start-Process fallback passed the raw URL after `-Command`, which parses everything as PowerShell SOURCE — so an OAuth authorize URL's `&` (query separators) would be read as PS's call/separator operator and the URL mangled or split, breaking the last recovery path on locked-down Windows (both cmd candidates failed + rundll32 unavailable). Wrap the URL in a single-quoted PS string literal (verbatim form; escape embedded `'` by doubling). rundll32 keeps the raw URL (no shell). New test covers the multi-`&` URL and the quote-escape. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
What & why
Some Windows users installing the
.dxtbundle never saw the sign-in browser open for OAuth, so they couldn't authenticate.Root cause: on Windows
openInBrowserresolved on the child's"spawn"event — the momentcmd.exewas created, before its internalstartbuiltin actually handed the URL to the default browser. A silent no-op (no default-browser protocol association, a locked-down shell / AppLocker, a corruptHKCR\http\shell\open) went undetected:browserOpenFailedAtBootstrapstayedfalseand the user was told "a browser may have opened" when nothing did.Change
openInBrowser(Windows only) now waits (bounded — 800ms forcmd start, 1200ms otherwise) for each launcher's exit code, treats a non-zero exit as failure, and falls through to shell-free launchers:rundll32 url.dll,FileProtocolHandler(Explorer's ShellExecute path — no command interpreter, honest exit code) then PowerShellStart-Process. Spawns withdetached:falseon Windows so exit is observable; keepswindowsVerbatimArguments.AUTH_REQUIREDenvelope honestly reports the browser couldn't be opened and shows the clickable sign-in link.spawn(the #3805 headless-hang fix;open/xdg-openare the hand-off).&-quotingcmd startcandidate is unchanged and still tried first; the new shell-free launchers live in a separatewindowsFallbackCandidates()so the #3801 "every candidate is quoted" pin stays green.bin.tsshutdown:browserOpenInFlightwait 1.5s → 3s for the multi-launcher walk..dxt/.mcpbrebuild via existing release CI.Tests
New files only (existing
oauth-browser-open*.test.tsuntouched):oauth-browser-open-win32-candidates.test.ts—browserOpenCandidateswin32 head stays the pinned cmd pair;windowsFallbackCandidatesreturns rundll32 then powershell with the raw URL.oauth-browser-open-win32-exit-wait.test.ts— cmd exit-0 resolves without spawning fallbacks; cmd no-op (exit 1) falls through to rundll32; all non-zero → rejects; cmd never-exits → resolves via timeout;detached:falseon win32 /trueon linux; POSIX still resolves onspawnwithout waiting for exit (protects #3805).pnpm -r build(dxt bundle builds + staged server starts + version self-check),pnpm -r test(core 494, mcp 512, promptforge 16), andpnpm -r typecheckall green.No eval coverage for this change — it's a platform browser-launch fix, not a tool/prompt/
WORKFLOWS.mdbehaviour change.Closes https://github.com/leadbay/product/issues/3839