Introduction¶
DeepSeek Harness (DSH) follows a “everything is a plugin” philosophy, but the theme layer is an exception: DSH’s Appearance picker (light/dark/system) is not open to third parties, and the theme registry does not accept writes from plugins. Previously, third-party plugins lacked a standard entry point to customize the entire color scheme of the web interface.
The dsh-theme-palettes introduced below takes a different path: instead of touching the theme registry, it overlays the palette onto the current theme via a layer of theme.overrideTokens, while also providing a themePalettes registration API, allowing any plugin to contribute its own palette.
What is this¶
dsh-theme-palettes (RainbowDashy/dsh-theme-palettes) is the color scheme infrastructure for DSH, solving two things:
- Built-in VSCode Red, Solarized Dark, and Solarized Light palettes, ready to use out of the box;
- Allows third-party plugins to register their own palettes via the
themePalettesAPI without modifying DSH’s theme registry.
License: MIT.
Core Features¶
Three Built-in Palettes¶
The three built-in palettes use the IDs vscode-red, solarized-dark, and solarized-light. Each palette ports the colors block from a reference theme to DSH’s --dsw-* design tokens:
- The two Solarized palettes each contain 89 tokens;
- VSCode Red contains 87 tokens; success/warn states preserve stock values.
The full token mappings are maintained in src/palettes.js in the repository.
Overlay via overrideTokens without Touching the Theme Registry¶
- Plugins do not register with the harness theme registry and never call
setTheme—DSH’s Appearance picker (light/dark/system) itself cannot be extended by third parties. - Palettes are overlaid on the current theme via a single
theme.overrideTokenslayer, overwriting by token; as long as the plugin is loaded, the overrides remain in effect. - The System appearance is first resolved to light or dark by the OS, then mapped to the corresponding palette; the mapping is re-triggered when the OS color scheme changes.
- Removing the plugin restores the stock (default) palette; the default configuration is
dark: defaultandlight: default.
Registration API for Third-Party Authors¶
Palettes are pure data. Third-party plugins register their palettes via the registerPalette method of the themePalettes service:
{
inject: ['themePalettes'],
apply(ctx) {
ctx.themePalettes.registerPalette({
id: 'my-package/ocean', // Recommended to use the owning package name as the namespace prefix
label: 'Ocean',
tokens: {
'--dsw-alias-bg-base': '#0b1e2d',
// ...
},
});
},
}
After registration, the palette appears in the configuration dropdown and directory list, on par with other built-in palettes. Refer to the repository README for full registerPalette parameters.
Installation and Enablement¶
Install using the dsh plugin command (profile is web):
dsh plugin --profile web add "github:RainbowDashy/dsh-theme-palettes"
After installation, restart the web server to let the new composition row enter the boot graph:
dsh web
Two optional installation methods:
# Fixed branch or tag
dsh plugin --profile web add "github:RainbowDashy/dsh-theme-palettes#main"
# Install from local checkout
dsh plugin --profile web add "link:/path/to/checkout"
The link: method makes your edits take effect in real-time; the file: method takes a snapshot of the directory.
Selecting a Palette¶
- Open Settings → Plugins → Plugin Configuration and expand the “Theme palettes” card.
- Use the “Light appearance uses” and “Dark appearance uses” dropdowns to select a palette for the corresponding appearance; the dropdown provides
Defaultplus all registered palettes. - The card also contains a directory list showing the base + accent duotone preview, label, ID, and built-in/3rd-party markers for each palette.
Changes take effect in real-time and are persisted to the user settings document $DSH_HOME/settings.yaml under the theme-palettes namespace, persisting across restarts:
{
"theme-palettes": {
"dark": "solarized-dark",
"light": "solarized-light"
}
}
Fail-soft handling: When a configuration references a palette ID that hasn’t been registered, it is handled as default and displayed as “(unavailable)” in the dropdown. If the host-side persistence is unavailable, the UI displays a “not persisted” hint.
Requires rc7¶
Configuration read/write depends on rc7’s standard settings surface:
- rc7 removed the settings namespace whitelist; only the standard settings surface can serve third-party namespaces, so this plugin maps the
theme-palettesnamespace to the user settings document alongside first-party namespaces; - The private
/api/theme-palettesroute used by rc6 and earlier no longer exists and is unavailable on older DSH versions.
Use Cases and Notes¶
Suitable for two types of people:
- Users who want to change the overall surface color scheme of the DSH web interface without modifying harness source code;
- Plugin authors who want to bundle a color scheme with their DSH plugin—the palette is pure data and can be registered immediately.
Notes:
- Plugins only override surface/chrome tokens. Reference theme
tokenColors(syntax highlighting) are intentionally excluded because DSH’s theme layer only exposes surface tokens; there are no corresponding tokens for code color rules. - Overrides remain in effect as long as the plugin is loaded; removing the plugin restores the stock palette.
- Plugins run with the current dsh process permissions; please check the source code and license yourself before installing (this plugin is MIT).
Conclusion¶
dsh-theme-palettes turns the DSH interface color scheme into a pluggable infrastructure using a theme.overrideTokens layer and a registration API: it includes three ready-to-use palettes and leaves a standard entry point open for third-party authors.
For more information, see the repository and community directory (the community directory is a separate site with no official affiliation with DeepSeek / Huafans):
- GitHub: https://github.com/RainbowDashy/dsh-theme-palettes
- Community Plugin Directory: https://www.skillhub.cn/plugins/RainbowDashy/dsh-theme-palettes