Repository navigation
fix(accounts): open the browser for a WSL account sign-in - #29566
Conversation
|
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 7 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to
|
A WSL Add account / Sign in again ran the provider CLI inside the distro, where stock distros have no opener, so no browser opened. Claude's link is now caught by the same BROWSER stand-in Copy link uses, Codex's by the link it already prints, and the desktop opens it after validation.
…ll login window Addresses review: watch the login's cancel signal before opening, give auto-open the whole login window to receive Claude's link, log the refused host, and cover cancel-before-delivery and service wiring in tests.
fd8b0df to
ccbfcd2
Compare
… stand-in does (#29682) The fake Claude wrote .orca-sign-in-browser.link directly, so the link poller could read it between create and write, see an empty link, and end the sign-in. Write a temp file and rename it into place, as the real stand-in script does. Flake introduced with the tests in #29566.
ELI5
When you add a Claude or Codex account that lives inside WSL, Orca now opens the sign-in page in your Windows browser, the same way a normal account add does. Before this, nothing opened and you had to click "Copy link" and paste the link yourself.
What Changed
Before: Settings → AI Provider Accounts → pick a WSL location → Add account (or Sign in again). Orca starts the provider's login program inside the Linux distro. That program tries to open a browser from inside Linux. Most distros have no way to do that (no
xdg-open,wslviewor$BROWSER), so nothing appears. The login sits and waits until the user finds Copy link.After: For WSL logins only, Orca catches the sign-in link and opens it on Windows itself:
BROWSER=true), so a distro that does have an opener doesn't get a second tab.claude.com/claude.aiwith a callback to this computer, orauth.openai.com). Anything else is logged and dropped, and it is never opened.Why
The link was already reaching Orca (Copy link proves it), and the sign-in callback already reaches WSL once a browser loads the link. The only missing piece was opening it. Reusing the existing capture paths keeps one way of catching each provider's link and adds no new IPC or renderer surface.
Alternatives considered:
wslu/xdg-openin the distro: needs root and changes the user's system.BROWSERshim callingcmd.exe /c start: AGENTS.md flags that pattern as an EDR signal, and it would pass an unvalidated URL to a shell.Linked Issue
Internal bug E19 (WSL bridge / WSL host). External PR #12023 attempted the Claude half on an older base; it has been stale since August and doesn't cover Codex.
Visual Proof
N/A. There is no on-screen change in Orca. The change is that a browser tab now opens on Windows, which needs a real Windows + WSL machine to show.
Testing
pnpm tcpasses.pnpm vitest run --config config/vitest.config.ts src/main/claude-accounts src/main/codex-accounts src/main/ipc/account-sign-in-link-opener.test.ts: 85 files and 676 tests pass.New tests:
account-sign-in-link-opener.test.ts: valid Claude and Codex links open. Plain http,file:,javascript:, custom schemes, malformed text, an empty string, credentials in the link, explicit ports, lookalike hosts, the wrong provider's host, and a Claude link calling back to a non-local host are never passed toopenExternal.claude-login-session.test.ts: a WSL login opens the link once and cleans up the stand-in. A WSL Copy link copies and never opens. A local login gets no stand-in and nothing is opened. A WSL login with no opener (orcad) is unchanged. A bad link is not opened and the login is not killed. If the stand-in can't be written, the login runs unchanged.codex-login-session-wsl-open.test.ts: a WSL login opens the printed link, keeps it for Copy link, and suppresses the distro opener. With no opener the login is unchanged. A non-https link is not opened. A local login is untouched.wsl-codex-command.test.ts:BROWSER=trueis added only when Orca opens the link.Platforms: unit tests on macOS. Not tested on a real Windows + WSL machine.
I manually tested these changes locally
Automated tests added/updated, or explained why not below
AI Disclosure
Review
An adversarial reviewer agent reviewed the change. Its findings are addressed in follow-up commits.
Agent skill upstream boundary
Notes
isClaudeLocalSignInLink) is reused and tightened with no-userinfo and no-port rules.orca account addCLI runs the login in the user's own terminal. Neither path is touched here.Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)