🐛 fix: Restore MCP App Rendering and Startup

[dustinhealy]

Summary

PR #13831 was rebased and retargeted to canary immediately before merge. Following that integration, MCP Apps could be detached from their originating tool calls and rendered at the bottom of the message, fail their initial bridge initialization until Retry, fail when bundled code resolved against a blob: document URL, or be blocked by an inherited X-Frame-Options header. Validation could also be delayed or blocked while loading unrelated MCP server configurations.

This change restores tool-owned inline rendering, makes bridge initialization safe under React Strict Mode and iframe navigation races, loads opaque inner App documents through srcdoc, binds bridge messages to the exact live iframe and sandbox origin, removes conflicting inherited frame headers at the sandbox boundary, and resolves only the MCP server referenced by the persisted App binding.

How it works

Tool result
  → owning tool content part
    → MCPAppViews
      → validate exact persisted server binding
        → resolve App resource and CSP
          → connect exact-source/exact-origin bridge transport
            → navigate outer sandbox
              → load opaque inner View with srcdoc

The inner View remains origin-opaque and retains the existing CSP injection, nonce attestation, liveness heartbeat, parent-origin binding, and bounded message queues.

Type of change

• Bug fix
• Tests / tooling / CI

Testing

1. Verified Apps remain beneath the tool calls that produced them.
2. Verified the bridge initializes during React Strict Mode effect replay without requiring Retry.
3. Verified bridge messages from the wrong iframe source or origin are rejected.
4. Verified bundled App documents load through the opaque srcdoc View.
5. Verified inherited frame headers are removed or replaced according to the sandbox policy.
6. Verified persisted App validation resolves only the referenced MCP server.

Tested environments/configuration:

• Browser: Chromium through Playwright
• MCP Apps: enabled with local reference and integration servers
• Lighthouse server: isolated local harness on port 3180
• Base branch: canary

Automated tests:

• Client MCP App, bridge, sandbox, and inline-placement suites: 155 passed
• API sandbox-controller and MCP registry suites: 113 passed
• npm run typecheck in client
• npx tsc --noEmit in packages/api
• ESLint, Prettier, import sorting, and affected static checks
• Lighthouse: LCP 3555 ms (limit 4500 ms), CLS 0.0169 (limit 0.1), TBT 24.23 ms (limit 500 ms)

Screenshots / recordings

These captures show the local MCP App reference and integration servers rendering in LibreChat after the fix. The pre-fix failures occurred on the rebased and retargeted canary integration and are reproduced by the regression tests above.

Apps Testbed	Three.js

Basic React	Budget Allocator

Risk / compatibility

The bridge transport and sandbox boundary are security-sensitive. Incoming messages must match both the live iframe window and its exact origin, and the inner App View remains origin-opaque. There are no database migrations, configuration changes, new dependencies, or changes to the MCP App model-context contract.

Checklist

• I reviewed my own changes
• Relevant tests have been added or updated
• Existing relevant tests pass
• The change does not introduce new warnings or errors
• User-facing or complex behavior is documented where necessary
• Required dependency changes have been merged/published
• Required documentation PR: N/A