app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

Overview Files Skills Packages Releases Dependencies Issues11 Breadcrumbs Pull Requests1 Activity
Closed general

HD update-restart brings VS Code up in a light theme despite settings.json = 'Dark 2026' (dark-default violation)

Drew Owens · 10d ago ·edited ·closed by John Lauer

Type: Bug report

Symptom: After restarting HD to apply an app update (2026-07-31, new build 458c322, built 8:34 AM), the VS Code workspace came up in a light theme. The user had to switch it back to dark by hand. This violates Adom's dark-by-default principle: a fallback should never be light.

What the workspace state shows (inspected in the container):

  • The user's setting is correct and was never changed to light: ~/.local/share/code-server/User/settings.json has "workbench.colorTheme": "Dark 2026". Its only local-history snapshot also reads "Dark 2026". So this was not a settings reset.
  • Both Dark 2026 and a sibling Light 2026 are built-in themes in this code-server build (1.124.2), shipped by the bundled theme-defaults extension (vs-dark and vs). Being built-in, Dark 2026 needs no third-party extension to resolve, so a missing extension is not the cause.
  • The adom.adom-vscode extension was intact (unchanged since Jul 27) and the workspace-updater did not run. So nothing in the workspace was reinstalled. This was the HD app update reloading code-server, not a workspace change.
  • product.json sets no forced default color theme (only an onboardingThemes picker list), so an unset theme falls to VS Code's compiled default.

What this points to: HD's update-restart reloads the code-server iframe (the same full workbench reload seen on sleep/resume, #60). On that reload VS Code did not apply the configured Dark 2026 from settings and painted a light theme instead, and it stuck until the user reselected dark. The user's setting was correct the whole time, so the theme the workbench applied came from cleared/booted state, not from settings.json.

The exact internal step that failed is not fully provable after the fact: the pre-reload workbench state that would show it lives in the WebView2 store and is gone. The confirmed part is that a correct Dark 2026 setting plus a built-in Dark 2026 theme still rendered light after an HD-update reload.

Asks:

  1. Never fall back to light. Per dark-default, if the workbench boots without a resolved theme, the fallback must be a dark theme (Dark 2026), not Light 2026 or a light default.
  2. Preserve or reassert the theme across an update-restart. Either keep the code-server workbench state through the reload so the applied theme survives, or after the reload force-apply workbench.colorTheme from settings.json (which was correct here) so a boot race cannot leave the user on the wrong theme.
  3. Since this rides the same full-workbench-reload path as the sleep/resume session loss (#60), a general fix that preserves workbench state across HD-driven reloads would address both.

Env: HD build 458c32216028151df03955b3c9f0e822c4dd7535 (Jul 31 8:34 AM), code-server 1.124.2, settings intact at Dark 2026.

2 Replies

John Lauer · 10d ago

TRIAGE (Fable 5, 2026-07-31): the SPECIFIC trigger here is a legacy image state, but a real kernel remains — rescoping, not closing.

Legacy part: this machine had "workbench.colorTheme": "Dark 2026" (a code-server BUILT-IN theme). HD has since moved to the Adom Studio theme set — the current golden image (v21) ships adom.adom-themes (Adom Studio Dark/Bright/Kickstand/Slate/Studio) and settings.json now defaults to "Adom Studio" (verified live on a current container). So the "Dark 2026 -> Light 2026" fallback path this report hit is an employee-on-an-older-image artifact HD no longer produces.

Still-valid kernel (image-independent, keep this open):

  1. Never fall back to a LIGHT theme. If the workbench boots without a resolved theme, the fallback must be dark. This holds regardless of image.
  2. HD does NOT reassert workbench.colorTheme after an HD-driven iframe reload — it only pushes the theme on an explicit change (src/lib/stores/settings.ts, the reload-only-on-colorTheme block). So a reload that drops the applied theme will not self-heal. Reasserting the configured theme after every HD-driven reload (shares the reload path with #7/#60 sleep-resume and #13 OOM) is the durable fix.

Reframing the issue to those two asks; dropping the Dark-2026-specific framing.

John Lauer · 7d ago

Closing as superseded by the theme-system rework, with the two still-valid kernels addressed or mooted:

  1. The trigger class is gone: HD no longer relies on code-server's built-in Dark 2026/Light 2026 pair. The golden image ships the adom-themes extension (Adom Studio family) and settings.json carries workbench.colorTheme for the chosen scheme; the theme data is versioned so the extension-cache staleness class is handled by the lockstep version bump.
  2. Reasserting the theme: as of today (2026-08-03) a scheme apply writes workbench.colorTheme PLUS the full font family and size set in one settings.json merge (a theme change was silently dropping the user's font size until this morning; fixed and verified live by corrupting the size, switching themes through the real UI, and reading back the corrected value). Since code-server reads settings.json on every load, an HD-driven reload now boots into a complete, self-consistent config.

If a light flash ever reappears on a current image, file it fresh against the Adom Studio pipeline; this report's machine state (Dark 2026) can no longer occur on shipped images.

Log in to reply.