Jason 19bf236e58 fix(deeplink): decode URL-safe Base64 in import confirmations ...

The renderer only fed input to `atob`, which rejects the URL-safe
alphabet (RFC 4648 §5). The backend, meanwhile, tries STANDARD,
STANDARD_NO_PAD, URL_SAFE and URL_SAFE_NO_PAD in turn, so a link whose
payload used `-`/`_` decoded fine on the way in but not on the way to
the screen.

`decodeBase64Utf8` swallows its own failure and returns the input
unchanged, so the mismatch was silent:

  - usage script  -> the confirmation showed opaque Base64
  - prompt        -> same
  - MCP config    -> `JSON.parse` threw, the catch returned null, and
                     the dialog rendered "0 servers" with an empty list

The MCP case defeated the server/argument display added earlier: a
one-character substitution made the whole list disappear while the
backend still imported the real `mcpServers` entry.

Normalize `-` to `+` and `_` to `/` before decoding, in both the primary
path and the last-resort fallback, so the two sides agree on what a
payload says. Standard Base64 contains neither character, so this cannot
misread standard input.

Adds the first tests for this shared decoder. They exercise the real
implementation rather than an injected stub, and assert their own
premise -- a payload whose standard encoding happens to contain no `+`
or `/` makes the URL-safe conversion a no-op and the test vacuous.

2026-07-29 10:22:30 +08:00

..

base64.test.ts

fix(deeplink): decode URL-safe Base64 in import confirmations

2026-07-29 10:22:30 +08:00

base64.ts

fix(deeplink): decode URL-safe Base64 in import confirmations

2026-07-29 10:22:30 +08:00