Copilot logo ignores widget theme/localStorage — Logo reads an unprovided theme context and follows OS prefers-color-scheme

[mcoslet-cloudx]

Describe the bug
In the Copilot widget, the logo (/logo?theme=...) does not follow the applied theme. It always follows the OS/browser prefers-color-scheme instead of the theme passed to mountChainlitWidget (or the persisted vite-ui-theme in localStorage). As a result, a copilot mounted with theme: 'light' on a machine set to dark mode renders a light UI but a dark logo (GET /logo?theme=dark).

Root cause (traced in copilot/dist/index.js, v2.11.1): there are two theme contexts.

The shadcn ThemeProvider (storageKey: "vite-ui-theme", defaultTheme = widgetConfig.theme || config.default_theme) provides context cIr. This themes the whole UI correctly and toggles the light/dark class on window.cl_shadowRootElement.
The Logo component's useTheme hook reads a different context, wNt (createContext({ theme: "system", setTheme: () => null })). There are zero wNt.Provider render sites in the bundle, so it always resolves to its default "system".
The logo variant is computed as:

variant = t.theme === "system"
? (matchMedia("(prefers-color-scheme: dark)").matches ? "dark" : "light")
: t.theme;
Because wNt is stuck at "system", variant collapses to the OS color scheme, and the widget theme prop / localStorage are ignored for the logo only.

To Reproduce
Steps to reproduce the behavior:

Set your OS/browser to dark mode (prefers-color-scheme: dark).
Embed the Copilot with an explicit light theme:
window.mountChainlitWidget({
chainlitServer: CHAINLIT_SERVER_URL,
accessToken: chainlitToken,
theme: 'light',
});
Provide per-theme logos in public/ (logo_light.svg, logo_dark.svg) and leave [UI] logo_file_url empty.
Open the copilot and inspect the logo element / Network tab.
See the UI rendered in light (correct) but the logo requested as GET /logo?theme=dark (logo_dark.svg) — and localStorage.getItem('vite-ui-theme') is "light".
Confirmation: DevTools → Rendering → "Emulate prefers-color-scheme: light" flips the logo to light while the rest of the UI is unchanged, proving the logo is OS-driven rather than theme-driven.

Expected behavior
The logo should follow the same resolved theme as the rest of the copilot — i.e. the theme passed to mountChainlitWidget (and/or the persisted vite-ui-theme). Mounting with theme: 'light' should request GET /logo?theme=light and render logo_light.svg, regardless of the OS color scheme. The Logo hook should read the same context that ThemeProvider provides (cIr), or wNt should be given a provider.

Screenshots

Storage panel showing vite-ui-theme = light.
Rendered logo element:<img src="http://localhost:8000/logo?theme=dark&" alt="logo" class="logo w-[100px]">.

Desktop (please complete the following information):
OS: macOS (system appearance: Dark)
Browser: Firefox (DevTools shown); reproducible on Chromium as well
Version: Chainlit 2.11.1 (copilot widget)

Smartphone (please complete the following information):
N/A (not device-specific; depends on prefers-color-scheme, so any device in dark mode reproduces it)
Additional context

Workaround: setting [UI] logo_file_url to a single URL bypasses the ?theme= path entirely (getLogoEndpoint(theme, url) => url || /logo?theme=${theme}), so the logo no longer depends on the broken context. Trade-off: one logo for both themes.
The affected hook is Pje (the Logo's useTheme) reading context wNt; the working provider is uIr providing context cIr. Aligning the two (or adding a wNt.Provider) should fix it.
Likely also affects any other component consuming the same wNt-based hook, not just the logo.

Additional context
Context for screenshots:
localStorage.setItem('vite-ui-theme', "light"); // beat the provider's stored value
window.mountChainlitWidget({
chainlitServer: server,
accessToken: access_token,
theme: "light",
});

This bug report — including the root-cause trace through the copilot bundle — was investigated and written with Claude Opus 4.8 (High reasoning).

[dosubot]

Hi @mcoslet-cloudx! I'm Dosu and I'm helping the Chainlit team.

Your root-cause analysis is accurate. The Logo component imports useTheme from a relative ./ThemeProvider [1], and in the copilot bundle, if that hook resolves against the wrong context (one without a matching Provider rendered above it), it falls back to the default "system" value — which then collapses to window.matchMedia('(prefers-color-scheme: dark)').

There are two custom ThemeProvider implementations in the codebase — one for the main frontend [2] and one adapted for Shadow DOM in the copilot [3]. The copilot version correctly targets window.cl_shadowRootElement and respects the widget config theme, but the Logo component's useTheme call appears to bind to the other (unprovided) context during bundling.

This has been partially addressed before:

• PR Fix: Resolve transparent UI issue in Copilot Light Mode #2768 (merged) fixed CSS selector scoping for dark/light mode in the Shadow DOM [4], but didn't resolve the React context mismatch for the Logo hook specifically.
• PR feat: real-time notifications + UI fixes for industrial deployment #2960 (currently open) includes further UI fixes including logo URL resolution and improved ThemeProvider isolation [5]. This may address or be closely related to your issue.

I'd recommend checking whether PR #2960 resolves this for you once it's merged. In the meantime, your workaround of setting [UI] logo_file_url to a single URL is the most reliable path since it bypasses the ?theme= logic entirely.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[mcoslet-cloudx]

Thanks, @dosu, for info, PR #2768 is really important for us too, but I see it's closed due to inactivity, could you reopen it or give maintainers a follow-up?

[dosubot]

@mcoslet-cloudx Unfortunately, I'm not able to reopen PRs or take actions on GitHub — I can only research and provide information.

Looking into it, PR #2768 [1] was closed without being merged, and I don't see evidence that its CSS fix (scoping selectors from #shadow-root-container to #cl-shadow-root) was incorporated into another PR. The fix itself was minimal (a single change to libs/copilot/src/index.css), so it should be straightforward to revive.

I'd suggest pinging the maintainers directly here or on the PR to ask about reopening it or cherry-picking the fix — especially since it's relevant to your logo theme issue as well. You could also reference this issue (#2976) on that PR to show there's continued demand for the fix.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[github-actions]

This issue is stale because it has been open for 14 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.