fix(auth): caret-escape cmd metacharacters when opening the browser on WSL

[scottlovegrove]

Symptom

On WSL, <cli> auth login (any DCR/OAuth consumer) pops a Windows dialog:

Windows cannot find '\https://todoist.com/oauth/authorize?resource=https%3A%2F%2F…'

instead of opening the browser. The URL is truncated at the first & and treated as a file path.

Root cause

openViaCmdExe opens the browser via cmd.exe /c start "" "<url>", wrapping the URL in double quotes to stop & from splitting the command line. Under WSL that doesn't work: the interop layer re-quotes argv entries itself, mangling the literal quotes, so & leaks through to cmd.exe as a statement separator. Only the prefix up to the first & reaches start; Windows then tries to open that fragment as a path.

Two compounding bugs, both confirmed with a real cmd.exe on WSL:

1. The surrounding quotes don't survive interop → & was never actually protected (cmd reported 'response_type' is not recognized… for each &-separated param).
2. url.replaceAll('%','%%') does not collapse on the cmd /c command line (only inside batch files), so %3A → %%3A would have corrupted every percent-encoded byte even when the command did run.

Only OAuth consumers that override openBrowser (e.g. todoist-cli, which routes through the open package) dodged this; consumers on the default opener hit it every login.

Fix

Caret-escape cmd's metacharacters (& | < > ^ ( ) ") instead of quoting — caret escaping survives WSL interop because there are no quotes for it to mangle — and leave % untouched (OAuth URLs are RFC 3986 %HH, which never matches cmd's %NAME% env-expansion; there's no command-line caret-escape for %, and doubling corrupts %HH).

Extracted as a pure, exported escapeUrlForCmd and unit-tested. Verified end-to-end against a real cmd.exe on WSL: the escaped string round-trips to the exact URL (carets stripped), & is protected, %HH preserved.

Tests

• Updated the WSL-routing test (it asserted the old quoted/%% behavior).
• Added a focused escapeUrlForCmd unit test (per-metacharacter escaping + percent-encoding round-trip).
• Full suite green (517).

🤖 Generated with Claude Code

[doistbot]

Thank you Scott for thoroughly diagnosing and addressing the WSL browser-open bug 🤗.

Few things worth tightening:

• Although caret-escaping handles command metacharacters well, cmd.exe will still treat certain valid percent-encoded sequences (like %C3% in %C3%A9) as environment variables; bypassing cmd.exe entirely to launch the browser would be a safer way to prevent URL corruption on WSL.

I also included a few optional follow-up notes in the details below.

Optional follow-up note (1)

• [P3] src/auth/flow.test.ts:527: These assertions duplicate the escaping logic checks already covered by the dedicated escapeUrlForCmd test below. Since you are already asserting expect(args).toEqual(['/c', 'start', '""', escapeUrlForCmd(url)]) on line 524, lines 527-532 can be removed to keep this test strictly focused on the routing behavior.

_{Share Feedback • Review Logs}

[doist-release-bot]

🎉 This PR is included in version 0.25.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀