Claude Web widget rendering fails: _meta.ui.domain hash uses resource request path instead of connector URL

[akjuno]

Bug

Widgets registered via registerWidget fail to render in Claude Web with an "Unable to reach [server]" error. The same widgets render correctly in Cursor and other MCP hosts.

Root cause

In registerWidgetResource (dist/server/server.js), the Claude-specific _meta.ui.domain hash is computed from the resource request URL, not the MCP connector URL:

const pathname = extra?.requestInfo?.url?.pathname ?? "";
const url = `https://${hostFromHeaders}${pathname}`;
const hash = crypto.createHash("sha256").update(url).digest("hex").slice(0, 32);

Claude Web expects domain to equal sha256(connectorUrl).slice(0,32) + ".claudemcpcontent.com", where connectorUrl is the URL the user entered when adding the MCP connector (e.g. https://mcp.fiji.so/mcp).

The pathname from extra.requestInfo.url.pathname is the path of the resource being fetched (typically "/"), not the /mcp endpoint path. So Skybridge hashes https://mcp.fiji.so/ instead of https://mcp.fiji.so/mcp, producing a different hash that Claude rejects.

Confirmed with hash comparison

https://mcp.fiji.so/   -> e33d66d6360c03b5787778d5d39cb0c6  (what Skybridge produces — rejected)
https://mcp.fiji.so/mcp -> 0a438b56404e81245c5485e96ce8e529  (what Claude expects — correct)

Suggested fix

Use the known MCP endpoint URL (from env var or server config) instead of the resource request path when computing the Claude domain hash. For example:

const url = process.env.MCP_SERVER_URL || `https://${hostFromHeaders}${extra?.requestInfo?.url?.pathname ?? ""}`;

Or better: derive the connector URL from the server's own configuration rather than relying on an env var.

Workaround

Using patch-package to apply the one-line fix above to dist/server/server.js.

Environment

• Skybridge v0.35.8
• Claude Web (claude.ai) as MCP host
• Connector URL: https://mcp.fiji.so/mcp

[valentinbeggi]

Hey @akjuno, thanks for the detailed report.

A workaround was shipped in skybridge@0.35.20 (PR #687): the Claude domain hash now prefers an x-alpic-forwarded-url request header. Our cloud platform already injects it, so apps hosted there are unblocked on >=0.35.20.
Self-hosted: have your proxy/CDN set x-alpic-forwarded-url: https://mcp.fiji.so/mcp

This is a workaround, making the server depend on a header for its own connector URL isn't great. Thinking about a cleaner long-term fix.

Please tell me if it helps you

cc @fredericbarthelet

[fredericbarthelet]

Hey @akjuno, thanks for sharing your issue.
Could you let us know which version of @modelcontextprotocol/sdk your project is using?

The pathname from extra.requestInfo.url.pathname is the path of the resource being fetched (typically "/"), not the /mcp endpoint path.

I don't think Render is doing any path rewrite (like we do on Alpic hosting, mentioned by @valentinbeggi). I suspect however your SDK version to be too old to hydrate correclty the requestInfo, hence my question.

Indeed, skybridge@v0.35.8 should produce correct hash (with /mcp included) if you use at least @modelcontextprotocol/sdk@v1.27.0. Before that version, extra.requestInfo.url is not populated by the SDK. We only started enforcing this constraint for the SDK version with skybridge@v0.35.20, and that may be what you're missing.