Chat widget: Assistant UI font blocked by VS Code CSP (data: fonts); esm.sh font fallback #2

Status: known bug in the excalidraw-mcp chat widget. Fonts load from the Docker canvas instance (lead decision, 2026-10-02).

Symptoms (real VS Code, MCP Apps widget)

• 4× console errors per render: Loading the font '<URL>' violates the following Content Security Policy directive: "font-src 'self' <URL>".
• Cause: vite-plugin-singlefile inlines Excalidraw's UI font Assistant (weights 400/500/600/700) as data:font/woff2 URLs. VS Code's MCP App CSP (chatMcpAppModel.ts) sets font-src 'self' <resourceDomains> without data:.
• Impact: the widget's UI text (not the hand-drawn Excalifont) falls back to a system font. The drawing still renders.

Latent egress

Excalidraw packages/excalidraw/fonts/ExcalidrawFontFace.ts createUrls() always appends ASSETS_FALLBACK_URL (https://esm.sh/@excalidraw/excalidraw@<ver>/dist/prod/) after EXCALIDRAW_ASSET_PATH. If a local font fails, the browser falls back to esm.sh. This affects the widget and the main canvas.

Attempted fix (reverted)

On feat/mcp, commit d934f5b (reverted in 3496600):

• Externalize the Assistant faces to <canvas>/excalidraw-assets/fonts/Assistant/*.woff2.
• Patch out the esm.sh fallback in our Excalidraw build.
• Default XCLD_ASSET_ORIGIN to http://127.0.0.1:3100.

The widget then rendered blank in real VS Code, with no console errors. A headless emulator of VS Code's CSP, sandbox and message order rendered every image fine (9a38109, f96315b, 0680175), so the root cause wasn't reproduced. The gap is probably VS Code's webview substrate (pre/index.html, MessagePort, vscode-webview origin).

Next steps (when picked up)

• Capture the real widget DOM in VS Code: Webview Developer Tools, frame whose document.title === "Excalidraw App".
• Re-apply the fix one change at a time: Assistant externalization only, then the fallback patch, then the default origin.
• Consider @modelcontextprotocol/ext-apps AppBridge / examples/basic-host for a closer host emulation.