lotusTransparent=1 makes body/#root fully transparent (background: transparent !important) so the host's own wallpaper shows through the call surface's empty gutters. lotusTheme=1 is independent and, per its own comment, is only a "safe starting point" that overrides exactly two custom properties (--cpd-color-bg-canvas-default, --video-tile-background) rather than the full Compound token map. A host can therefore set lotusTransparent=1 without lotusTheme=1 (they're separate, uncoupled flags), leaving all of EC's text/icon colors computed against the default (dark, per requestedTheme) canvas token while the actual pixels behind them are whatever the host painted. Controls, name tags, and status icons that sit directly over the transparent gutter (not over an opaque tile background) have no backdrop, scrim, or forced-contrast rule to protect legibility if the host's real background is lighter/differently-hued than the assumed dark canvas.
How to trigger
Host sets lotusTransparent=1 (or sets lotusTheme=1 before finishing the "extend this block" TODO) behind a light or saturated wallpaper; call UI text/icons render with the same color logic as the default dark canvas.
Suggested fix
Either require lotusTheme=1 whenever lotusTransparent=1 is set (validate/log if not), or add a lightweight text-shadow/backdrop-filter guard on the elements that sit directly on the transparent canvas so legibility doesn't depend entirely on the host getting the palette match exactly right.
Filed from the September 2026 audit (branch lotus).
**Severity:** medium · **Type:** ux · **Confidence:** medium
**Location:** `src/index.css:88-107`, `src/useTheme.ts:61-65`
### Problem
`lotusTransparent=1` makes `body`/`#root` fully transparent (`background: transparent !important`) so the host's own wallpaper shows through the call surface's empty gutters. `lotusTheme=1` is independent and, per its own comment, is only a "safe starting point" that overrides exactly two custom properties (`--cpd-color-bg-canvas-default`, `--video-tile-background`) rather than the full Compound token map. A host can therefore set `lotusTransparent=1` without `lotusTheme=1` (they're separate, uncoupled flags), leaving all of EC's text/icon colors computed against the *default* (dark, per `requestedTheme`) canvas token while the actual pixels behind them are whatever the host painted. Controls, name tags, and status icons that sit directly over the transparent gutter (not over an opaque tile background) have no backdrop, scrim, or forced-contrast rule to protect legibility if the host's real background is lighter/differently-hued than the assumed dark canvas.
### How to trigger
Host sets `lotusTransparent=1` (or sets `lotusTheme=1` before finishing the "extend this block" TODO) behind a light or saturated wallpaper; call UI text/icons render with the same color logic as the default dark canvas.
### Suggested fix
Either require `lotusTheme=1` whenever `lotusTransparent=1` is set (validate/log if not), or add a lightweight text-shadow/backdrop-filter guard on the elements that sit directly on the transparent canvas so legibility doesn't depend entirely on the host getting the palette match exactly right.
---
_Filed from the September 2026 audit (branch `lotus`)._
jared
added this to the EC fork audit 2026-09 · Medium & Low milestone 2026-09-12 02:13:08 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: medium · Type: ux · Confidence: medium
Location:
src/index.css:88-107,src/useTheme.ts:61-65Problem
lotusTransparent=1makesbody/#rootfully transparent (background: transparent !important) so the host's own wallpaper shows through the call surface's empty gutters.lotusTheme=1is independent and, per its own comment, is only a "safe starting point" that overrides exactly two custom properties (--cpd-color-bg-canvas-default,--video-tile-background) rather than the full Compound token map. A host can therefore setlotusTransparent=1withoutlotusTheme=1(they're separate, uncoupled flags), leaving all of EC's text/icon colors computed against the default (dark, perrequestedTheme) canvas token while the actual pixels behind them are whatever the host painted. Controls, name tags, and status icons that sit directly over the transparent gutter (not over an opaque tile background) have no backdrop, scrim, or forced-contrast rule to protect legibility if the host's real background is lighter/differently-hued than the assumed dark canvas.How to trigger
Host sets
lotusTransparent=1(or setslotusTheme=1before finishing the "extend this block" TODO) behind a light or saturated wallpaper; call UI text/icons render with the same color logic as the default dark canvas.Suggested fix
Either require
lotusTheme=1wheneverlotusTransparent=1is set (validate/log if not), or add a lightweight text-shadow/backdrop-filter guard on the elements that sit directly on the transparent canvas so legibility doesn't depend entirely on the host getting the palette match exactly right.Filed from the September 2026 audit (branch
lotus).