Feature Description
Command Code to support one extra theme slot called custom. It would read ~/.commandcode/themes/custom/palette.json, layer it over the dark base, and repaint when the file changes. It should work everywhere a theme name works: config, --config theme=, /theme, and the
picker. The watcher should use fs.watch with an mtime poll fallback. And the palette JSON schema should be documented so desktop themes can target it.
Use Case
I run Omarchy. The system already picks one palette and repaints quickshell and the bar on omarchy theme set. Command Code sits outside that. Auto only looks at terminal background, so the TUI never matches the desktop and I have to restart it after a theme switch. A file-backed custom slot would let Omarchy publish its palette once and let Command Code follow it.
Additional Context
I proved this out locally with a patch. A small Python script turns colors.toml into a 77-key palette.json. I tested it on Matte Black and others in dark mode. I map flat keys onto USER_MSG_COLORS, DIFF_COLORS, STATUS_COLORS, TASTE_COLORS, PR_COLORS, MARKDOWN_COLORS, and LOGO_BANNER_COLORS, and the quickshell accent drives the TUI accent. A theme-set hook rewrites palette.json on every system switch. The watcher swaps in a fresh snapshot and calls applyTuiTheme("custom"). It repaints a running session in about two seconds. Partial palettes fall back to base tokens. I can share the scripts. They are bundle patches, not mergeable code, but they pin down the mapping and reload wiring. Open questions are whether this stays separate from auto, who owns per-desktop converters, and how to version the schema.
How important is this to you?
Nice to have
Feature Description
Command Code to support one extra theme slot called custom. It would read ~/.commandcode/themes/custom/palette.json, layer it over the dark base, and repaint when the file changes. It should work everywhere a theme name works: config, --config theme=, /theme, and the
picker. The watcher should use fs.watch with an mtime poll fallback. And the palette JSON schema should be documented so desktop themes can target it.
Use Case
I run Omarchy. The system already picks one palette and repaints quickshell and the bar on omarchy theme set. Command Code sits outside that. Auto only looks at terminal background, so the TUI never matches the desktop and I have to restart it after a theme switch. A file-backed custom slot would let Omarchy publish its palette once and let Command Code follow it.
Additional Context
I proved this out locally with a patch. A small Python script turns colors.toml into a 77-key palette.json. I tested it on Matte Black and others in dark mode. I map flat keys onto USER_MSG_COLORS, DIFF_COLORS, STATUS_COLORS, TASTE_COLORS, PR_COLORS, MARKDOWN_COLORS, and LOGO_BANNER_COLORS, and the quickshell accent drives the TUI accent. A theme-set hook rewrites palette.json on every system switch. The watcher swaps in a fresh snapshot and calls applyTuiTheme("custom"). It repaints a running session in about two seconds. Partial palettes fall back to base tokens. I can share the scripts. They are bundle patches, not mergeable code, but they pin down the mapping and reload wiring. Open questions are whether this stays separate from auto, who owns per-desktop converters, and how to version the schema.
How important is this to you?
Nice to have