You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(web): MCP App cards no longer flash white in dark mode while the app loads - #33352
In dark mode, MCP App cards on web and desktop are bright white blocks from the moment the frame loads until the app sends ui/initialize. For apps with a large bundle that is seconds. The <iframe> gets color-scheme: dark from the host, but the app document has no color scheme until the theme bootstrap hears from the host, so Chromium paints the child canvas opaque white.
Reproduced on main 1a43f4870d in the web app: a Claude thread called a synthetic MCP tool whose ui:// app sends ui/initialize 4 s after load. In dark mode both cards stayed white for about 4 s after switching back to the thread, and again after a full page reload. Light mode was unaffected.
Change
McpAppFrame adds a t3-color-scheme=<light|dark> query parameter to the frame URL when it first adopts it. The frame still keeps that one URL; later theme changes keep flowing through ui/notifications/host-context-changed.
The theme bootstrap that the server already injects into every app document reads that parameter and appends <meta name="color-scheme" content="…"> to the app's head before the app's own scripts run and before first paint. It uses a meta tag rather than an inline style on <html>, which would replace an app's own <html style> attribute. The captured fixture app sets no styles or color scheme of its own, so an app that sets color-scheme in its own CSS is not shown below.
The server route ignores the query string (the asset token is in the path), so older servers keep today's behaviour. Mobile sets no color scheme on its inner frame and is unchanged.
vp test run packages/shared/src/mcpApp.test.ts apps/server/src/http.test.ts: 39 passed, including a new test that the bootstrap applies only light/dark from the frame URL before any message arrives.
At e829b7b38f (main merged; upstream changes touch only mobile files): vp test run packages/shared/src/mcpApp.test.ts 15 passed; vp run check:changed: format, lint, knip, typecheck (35 packages), tests and React compiler all pass; CI 35/35 green.
Review at e829b7b38f: two independent reviewers, both merge, no findings. Both name the same trade-off, row C6 below. Neither change touches auth, sandboxing, CSP or the MCP tool surface; the parameter parse is linear (about 2 ms on 3000 malformed tokens).
Proof audit at e829b7b38f: all 57 PNGs and 10 recordings inspected; every delivered diff image recomputes exactly. C2–C5 are sufficient. An independent rebuild of C1 paints both cards dark before ui/initialize, as captured, but differs by 5,977 pixels: its seed turn (a real provider turn) wrote an extra "Worked for" row that moves the cards down 42 px. The C6 frames show the loading text losing contrast in the pre-initialize window, as described.
Real web app, headless Chromium 148, 1400×1022, DPR 1, fresh databases per side, a synthetic MCP app that initializes after 4 s. Captures at 807635d674; the later commits on the branch are a comment wording change and a merge of main that does not touch the changed files.
C1, T3 dark on a light browser preference, about 2 s after returning to the thread:
Diff0 is threshold 0, DiffT threshold 8/255, both amplified 32×. Only the two app canvases change; there are zero changed pixels outside them at threshold 0.
…app loads
The frame element declared the host's dark color scheme, but the app
document declared none until `ui/initialize` answered, so Chromium painted
the child canvas opaque white for as long as the app took to initialize.
The frame URL now carries the host's scheme in a `t3-color-scheme` query
parameter, and the injected theme bootstrap applies it before first paint.
Later theme changes still arrive through host-context-changed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Macroscope's review found this PR approvable — MCP App frames receive the existing host theme before initialization, preventing the white loading flash in dark mode. The change is limited to initial presentation and preserves subsequent theme updates.
No code changes detected at 7f2ac6d. Prior analysis still applies.
You can add or adjust custom eligibility rules. Learn more.
Reviewing files that changed from the base of the PR and between e829b7b and 7f2ac6d.
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
Trigger review
No actionable comments were generated in the recent review.
Walkthrough
The MCP App frame URL now includes the host’s current theme appearance. The theme bootstrap reads that parameter before host initialization and sets a color-scheme meta tag for light or dark.
Changes: MCP App theme initialization
Layer / File(s)
Summary
Bootstrap color scheme from frame URL packages/shared/src/mcpApp.ts, packages/shared/src/mcpApp.test.ts
The bootstrap reads the t3-color-scheme parameter and adds a color-scheme meta tag when its value is light or dark. Tests cover those values, normal, and a missing parameter.
Pass host appearance to frame apps/web/src/components/chat/McpAppFrame.tsx
When the asset succeeds and the frame source is unset, the frame adds the current theme appearance to the asset URL before setting its source.
Web frames receive the initial theme; mobile behavior remains unchanged. No material merge blocker was identified.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title names the actual change: MCP App cards stop flashing white in dark mode while the app loads. It is specific and follows the conventional commit form. The raw summary, PR objectives, and link…
Linked Issues check
Directly linked issue #33303 requires that MCP App cards not paint a white canvas in dark mode before the app sends ui/initialize. Its suggested approaches are a themed placeholder or setting the colo…
Out of Scope Changes check
The whole-PR changes touch three files in the reviewed diff: packages/shared/src/mcpApp.ts, packages/shared/src/mcpApp.test.ts, and apps/web/src/components/chat/McpAppFrame.tsx. Each change connects t…
Description check
The description covers the problem, change, linked issue, verification results, UI evidence, and untested areas. It does not identify explicit maintainer approval of the scope or explain why the fix q…
Full details: Title check
Explanation
The title names the actual change: MCP App cards stop flashing white in dark mode while the app loads. It is specific and follows the conventional commit form. The raw summary, PR objectives, and linked issue #33303 all describe this same fix, so the title matches the changeset.
Full details: Linked Issues check
Explanation
Directly linked issue #33303 requires that MCP App cards not paint a white canvas in dark mode before the app sends ui/initialize. Its suggested approaches are a themed placeholder or setting the color scheme before first paint. The PR uses the second approach.
Code evidence at head:
apps/web/src/components/chat/McpAppFrame.tsx: when the frame first adopts its URL, the code sets t3-color-scheme=<theme.appearance> on the asset URL. The URL is still set only once, so later theme changes use ui/notifications/host-context-changed as before.
packages/shared/src/mcpApp.ts: injectMcpAppThemeBootstrap reads MCP_APP_COLOR_SCHEME_PARAM from location.search. When the value is light or dark, it appends <meta name="color-scheme"> to document.head. The bootstrap script is placed after the doctype and optional CSP meta, before any app content or app script, so the parser places it in head before app scripts run.
packages/shared/src/mcpApp.test.ts: a new test runs the bootstrap in a VM with a mocked document. It asserts that dark and light apply a meta tag, and that normal or a missing parameter applies none.
The fix does not depend on the host message, so it covers the window before ui/initialize, which is the scope of #33303.
Uncertainty: I did not verify in code that theme.appearance resolves to light or dark and not system. The author reports headless Chromium captures for system and dark theme rows (C1, C3) that show the fix. Those captures are author-reported and I did not reproduce them. The unit test runs against a mocked document, not a real browser. Residual limitation (author-reported C6): a theme change before ui/initialize keeps the mount-time scheme. This is not a stated requirement of #33303.
Full details: Out of Scope Changes check
Explanation
The whole-PR changes touch three files in the reviewed diff: packages/shared/src/mcpApp.ts, packages/shared/src/mcpApp.test.ts, and apps/web/src/components/chat/McpAppFrame.tsx. Each change connects to #33303:
McpAppFrame.tsx: adds the color-scheme query parameter to the initial frame URL.
mcpApp.ts: adds the MCP_APP_COLOR_SCHEME_PARAM constant and the bootstrap logic that reads it and applies the meta tag.
mcpApp.test.ts: tests the new bootstrap behavior.
No unrelated change is present in the reviewed diff. The PR description states that the server route, mobile inner frame, and Electron app are unchanged. I did not inspect the server route or mobile code, so those statements are not verified here. They do not affect this verdict, because no server or mobile file appears in the whole-PR change set.
Full details: Description check
Explanation
The description covers the problem, change, linked issue, verification results, UI evidence, and untested areas. It does not identify explicit maintainer approval of the scope or explain why the fix qualifies without that approval.
Finishing Touches
Generate docstrings
Commit to this branch
Create a new PR
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Reviewing files that changed from the base of the PR and between 4f0b74e and 6d93911.
Files selected for processing: 3
apps/web/src/components/chat/McpAppFrame.tsx
packages/shared/src/mcpApp.test.ts
packages/shared/src/mcpApp.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.
Both captures: real web dev servers, Chromium 157 on Linux, dark appearance, 1280×800 CSS viewport, DPR 2, separate fresh databases and identical synthetic data.
Steps: seed a synthetic ui://apps/dataviz MCP App that delays ui/initialize by four seconds; open its thread; reload the page; observe through initialization. Tool output was replayed through the real adapter and orchestration. The attachment route, chat card and sandboxed iframe used each commit's production code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bugfixFix PR opened by an issue lead; enters the PR looppr:gate-failedA land gate failedsize:S10-29 changed lines (additions + deletions).vouch:trustedPR author is trusted by repo permissions or the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
juliusmarminge
added
bugfix
Problem
In dark mode, MCP App cards on web and desktop are bright white blocks from the moment the frame loads until the app sends
ui/initialize. For apps with a large bundle that is seconds. The<iframe>getscolor-scheme: darkfrom the host, but the app document has no color scheme until the theme bootstrap hears from the host, so Chromium paints the child canvas opaque white.Reproduced on main
1a43f4870din the web app: a Claude thread called a synthetic MCP tool whoseui://app sendsui/initialize4 s after load. In dark mode both cards stayed white for about 4 s after switching back to the thread, and again after a full page reload. Light mode was unaffected.Change
McpAppFrameadds at3-color-scheme=<light|dark>query parameter to the frame URL when it first adopts it. The frame still keeps that one URL; later theme changes keep flowing throughui/notifications/host-context-changed.<meta name="color-scheme" content="…">to the app's head before the app's own scripts run and before first paint. It uses a meta tag rather than an inline style on<html>, which would replace an app's own<html style>attribute. The captured fixture app sets no styles or color scheme of its own, so an app that setscolor-schemein its own CSS is not shown below.The server route ignores the query string (the asset token is in the path), so older servers keep today's behaviour. Mobile sets no color scheme on its inner frame and is unchanged.
Scope and approval
Fixes #33303
Verification
vp test run packages/shared/src/mcpApp.test.ts apps/server/src/http.test.ts: 39 passed, including a new test that the bootstrap applies onlylight/darkfrom the frame URL before any message arrives.e829b7b38f(main merged; upstream changes touch only mobile files):vp test run packages/shared/src/mcpApp.test.ts15 passed;vp run check:changed: format, lint, knip, typecheck (35 packages), tests and React compiler all pass; CI 35/35 green.e829b7b38f: two independent reviewers, both merge, no findings. Both name the same trade-off, row C6 below. Neither change touches auth, sandboxing, CSP or the MCP tool surface; the parameter parse is linear (about 2 ms on 3000 malformed tokens).e829b7b38f: all 57 PNGs and 10 recordings inspected; every delivered diff image recomputes exactly. C2–C5 are sufficient. An independent rebuild of C1 paints both cards dark beforeui/initialize, as captured, but differs by 5,977 pixels: its seed turn (a real provider turn) wrote an extra "Worked for" row that moves the cards down 42 px. The C6 frames show the loading text losing contrast in the pre-initialize window, as described.807635d674; the later commits on the branch are a comment wording change and a merge of main that does not touch the changed files.C1, T3 dark on a light browser preference, about 2 s after returning to the thread:
1a43f4870d807635d6741a43f4870d↔807635d6741a43f4870d↔807635d674Recordings: C1-before.mp4 · C1-after.mp4
Diff0 is threshold 0, DiffT threshold 8/255, both amplified 32×. Only the two app canvases change; there are zero changed pixels outside them at threshold 0.
ui/initializeFull evidence index with every recording, trace and timestamp: Evidence.md. Fixture matrix: fixture-matrix.md. Seeding and driver scripts, including the synthetic MCP server: seeding-and-drivers.zip.
Not checked: the Electron desktop app itself (Chromium covers its render path), Safari, native mobile (unchanged code path), and a real Datadog app.
AI-assisted; verified with the tests and tools listed above.
🤖 Generated with Claude Code