inspector

Closes #2055 Problem in read the UI resource's sandbox metadata straight off : But describes the value of *, not itself ( ; the tool side of this same file already reads via ). So for every spec-conforming app, and were → returned → emitted , and the app's declared never reached the sandbox. Any App doing network work was unusable in the Apps tab. Fix Read the metadata from , through a small helper that type-guards the value so a malformed bag degrades to "no hints" rather than being cast blindly. Three carriers, consulted most-specific first: 1. the content item's own ; 2. the read result envelope's — , what a callback returns, types at that level; 3. the matching entry's, which documents as the static default a host reviews at connection time, and which a read content item explicitly takes precedence over. Whichever is found first wins outright — the levels are not merged, since a server restating only at a more specific level means that to be the whole grant, not a patch over the broader one. The app-supplied bag is also screened before it reaches the sandbox (, beside the existing ). The proxy's tests each key for truthiness, so would have read as a grant; only the spec's empty-object marker now counts, everything else fails closed. Nothing screened it before because, thanks to this same bug, no permissions ever reached the proxy at all. The listing reaches the factory through a new optional dep, , wired in for both bridge factories from the resources list. Optional because a host with no listing — or one whose listing omits this URI, which is common for resources — must be unaffected rather than broken. Tests 's fixture now builds the real wire shape (), so the existing CSP/permissions assertions exercise the spec structure rather than a shape no server sends. Cases added: each of the three carriers is honored, and the precedence between them (content item > result envelope > listing) none present → still renders under an unnested* bag is ignored — locks the regression direction covers the permissions screen, including adds a case for the App-level wiring itself (a pass-through spy over the factory), since the factory's own tests inject the dep and so cannot see that wiring break. Screenshots None — the change has no visual surface. It alters the `mcp-app-http.json_meta.uiconnectDomains_meta.ui.domainMcpUiSandboxResourceReadyNotification.paramsdomainOrigin: nullsandbox_proxy.htmlallow-same-origindomainnpm run ci` passes.

Closes #2067 Corporate-proxy users cannot connect to any remote MCP server from v2 — a regression from v1 that has been present since 2.0.0. The reporter's investigation was thorough and correct; I reproduced both defects end to end before fixing them. Two independent bugs 1. The web and TUI bundles shipped an unloadable copy of .* It was declared in the root and manifests but named in no client's tsup list, and tsup auto-externalizes only what the nearest manifest declares. So esbuild inlined 1.05MB of it: is CommonJS, so the emitted chunk's hits esbuild's ESM shim: The rejected surfaced as "HTTPS_PROXY / HTTP_PROXY is set but the package is not available" — telling users to install a package that was already present, and which could not have helped: the specifier had been rewritten to a relative chunk at build time, so no user-side install could ever satisfy it. 2. A userland dispatcher is incompatible with Node's built-in . injected a userland into Node's built-in . That couples two different copies of undici at the dispatcher handler interface, which is not stable across majors: So the CLI — which did externalize undici and loaded the real package — failed differently, and fixing the bundling alone would only have converted the web/TUI failure into the CLI's. The fix Both halves of the pair now come from userland undici — its and its . That keeps the dispatcher handler inside one copy, which is why it works unchanged from the Node 22.19 floor through Node 26. Deleting the wrapper in favor of Node's native was considered and rejected on measurement — it is not supported at our floor: Responses are re-wrapped as genuine global objects (streaming preserved). undici's is a different class, so is for it — and the SDK branches on exactly that in , which would degrade every OAuth error to . The proxy moved to the bottom of the fetch stack — for the Node clients, and the default for the web backend (its one caller that supplies no ). Proxying means substituting the fetch, not decorating one, so wrapping a supplied would discard it. As the reporter notes, sets unconditionally (), so a fix keyed off "was a supplied?" would have fixed web and silently left the CLI and TUI broken. A side effect worth having: OAuth discovery and token requests are now proxied too — they run through and never were before. Verification Driven through a real forwarding proxy against a real MCP server (), with the built clients: All requests confirmed to traverse the proxy (18 forwarded requests logged). Before this change, the web backend failed on every Node version with the misleading toast, and the CLI failed on 22/24 with . Guarding it is now root-declared only and named in all three tsup lists, per the placement rule in . The two installs had already drifted (root vs cli ). New fails if any package a client declares was inlined into that client's bundle anyway. It reads the built output, not the config — the two disagreed for four releases — and derives what to check from each client's own array, so a newly externalized package is covered without editing the guard. Wired into and the GitHub workflow, with table-driven unit tests via . Verified against the real pre-fix artifact, which it flags: The proxy tests now drive a real forwarding proxy rather than a mock. That is load-bearing: bug 2 was a runtime* interface mismatch, and no mock can catch it because no mock ever dispatches. The suite also pins the global- contract, , null-body statuses, and that no longer wraps a supplied . 's must-not-bundle rule (added by #2082) is extended with why slipped past it, and with the trap the reporter flagged — probing the bundled chunk with falsely succeeds, because it exposes a global that satisfies esbuild's guard. Mirrored into . Notes No UI change — no component, theme, or story is touched. The user-visible difference is that the connection succeeds instead of raising an error toast. drops ~1.05MB and the same, since neither vendors undici any more. 🤖 Generated with Claude Code https://claude.ai/code/session_01JTHVxSu8AUgHRLvo1ntZ8H

Problem Every browser-based check in this repo runs in Chromium only: Firefox and WebKit appear nowhere — not in a script, not in the vitest browser config, not in the workflow. That is fine for most of the web client, whose behavior is React and Mantine. It is not fine for the MCP Apps sandbox, which is the one part of the Inspector built out of the browser primitives that actually diverge between engines: a CSP `srcdocsrcdocabout:blanksandboxPermissions-PolicyallowpermissionspostMessagesandbox-csp.test.tsapproveCspSourcesbuildSandboxCspPolicyAppRendererAppsScreenAppElicitationHostPLACEHOLDER_SANDBOX = "data:text/html,…"srcdocui/initializesandbox-csp.tscreateAppBridgeFactory.tssmoke:web:appsmoke:web:elicitscripts/smoke-web-app.mjsscripts/smoke-web-elicitation.mjsloadChromium()smoke:web:browser.github/workflows/main.ymlnpx playwright install --with-deps chromium firefox webkitfirefoxwebkitsmoke:web:appsmoke:web:elicitplaywright install --with-deps smoke:web:elicit#1565` sandbox hardening, so fixing it narrowly for elicitation would leave the larger surface uncovered.