A fixed E4E4E4 segment was 1.04:1 against Kaolin Breeze's EBE8E4 -- an
invisible pill -- and a neutral grey reads as a foreign object on a warm
or cool background anyway. Read the background kitty is showing and place
the segment a fixed contrast step below it, so it keeps the theme's tint.
Default step is 1.12:1; __tide_terminal_segment_contrast overrides it.
Moving the segment invalidates the foregrounds, which are authored at
exactly 4.5:1 against E4E4E4 with no headroom, so re-aim them at the
derived segment by the single ratio the palette's shared luminance ceiling
moved by. That scaling runs in linear light, where luminance is a weighted
sum of the channels and so scales exactly; scaling the encoded channels
drifts further the darker a color gets, which is where the floor binds.
Also fix the baseline capture: the overrides are exported, so a Fish
started from a Fish that had already applied a palette was capturing that
palette as its dark baseline and could never restore dark. Drop inherited
globals first so the baseline comes from the universal scope Tide writes.
Dark mode is unchanged.
Catppuccin Latte sets tab_bar_background #BCC0CC, a grey noticeably
darker than its #EFF1F5 background, so in light mode the tab bar sat on
a band of its own colour. kitty.conf leaves the setting commented out --
kitty's default is to follow the terminal background -- but the
generated *-theme.auto.conf files are applied with priority over
kitty.conf, so the theme won and there was nowhere left to override it.
repair-auto-themes.sh already normalises macos_titlebar_color for the
same reason; give tab_bar_background the same treatment. The canonical
copies under theme-modes stay exactly as the themes kitten saved them.
Also picks up the current theme choices: SpaceGray Eighties for dark,
Catppuccin Latte for light.
`kitten theme` runs the themes kitten -- kitty accepts unambiguous prefixes
-- but the shim tested `$argv[1] = themes` exactly, so that spelling skipped
the capture and re-apply entirely. Before the theme-mode work that was
harmless, since nothing rewrote the automatic theme files; now the next
regeneration reverts whatever was just chosen, which is why picking a theme
stopped sticking.
Accept any prefix of "themes" at least two characters long. Verified that
themes/theme/them/th all trigger and icat still does not.
Saving a theme stopped sticking: the choice was captured only by the fish
`kitten` wrapper, so `kitty +kitten themes`, a keybinding or any non-fish
shell wrote <appearance>-theme.auto.conf directly and the next regeneration
overwrote it from theme-modes. The dark slot had already lost a pick that
way -- dark-theme.auto.conf held #0d0f31 while canonical dark said #2b2c2e.
Move the capture into apply-theme-mode.sh, which every path runs. It records
a cksum of each generated file after the repair step; on the next run a file
whose checksum differs was written by something else, so it becomes canonical
for that appearance. With no state recorded yet nothing is adopted, so a
first run cannot mistake a pinned mode's duplicated files for real choices.
The fish wrapper keeps only its useful part: re-apply the mode and reload so
the change shows at once.
theme-modes/dark.conf is the recovered #0d0f31 (1984). Covered by a new case
in tests/test_theme_mode.sh that writes the theme file with no shell involved.
Captures the current theme choices in the canonical store: theme-modes/
dark.conf is Galaxy and light.conf is GrokDay, both verified identical
to their source theme files.
The ping wrapper only asked whether the *target* had an AAAA record, never
whether this machine could reach over IPv6, so `ping ya.ru` ran ping6 and
died with "No route to host" while IPv4 worked fine.
Checking for a default v6 route is not sufficient either: this Mac has one
while holding only ::1 and fe80:: link-locals. So require a global unicast
address (2000::/3) as well as the route, which is the condition that
actually fails here.
ping4 is now platform-split rather than branching internally, since macOS
ping rejects -4:
macOS ~/.local/bin/ping (wrapper) and ~/.local/bin/ping4 -> /sbin/ping
Linux a fish function running `ping -4`
.chezmoiignore gates each side so neither lands where it cannot work.
Both themes used bg_terminal, on the assumption the name meant "the
terminal's background". It does not -- the shared Theme struct documents
it as "For terminal output blocks (currently unused, using bg_dark
instead)". The surface grok actually paints is bg_base, so GrokDay was
rendering brighter than grok itself (#f5f5f5 vs #eeeeee) and GrokNight
darker (#0a0a0a vs #141414).
GrokDay's color15 moves from bg_storm to bg (#f5f5f5): bg_storm is now
the background, so bright white would have been invisible against it.
Audited every slot in both files against the source palettes: each value
maps to a named palette color, no text color is under 3:1 on its
background, and cursor and selection overlays clear 4.5:1.
`kitten themes` treats every .conf in <config-dir>/themes as a user
theme, which the mode system's canonical store was sitting in -- so the
picker was offering three bogus entries named light, dark and
no-preference, and had been since that store was introduced.
Move the store to ./theme-modes so ./themes means only what the kitten
means by it, and repoint apply-theme-mode.sh, the kitten shim, the
run_after hook and the test at the new path.
GrokNight and GrokDay move into ./themes with the ## name/author/
license/upstream/blurb header the kitten reads, so they now show up in
`kitten themes` and `--dump-theme` resolves them.
theme-modes/dark.conf carries the #202020 theme that was already on
disk: the file had to be re-added at its new path, so that drift comes
along with it.
Ported from grok build's TUI themes, whose palettes are defined in
crates/codegen/xai-grok-pager-render/src/theme/{groknight,grokday}.rs in
xai-org/grok-build -- they are compiled RGB constants, not extractable
from the shipped binary.
background uses grok's bg_terminal and cursor uses accent_user, which
grok sets over OSC 12 at startup, so a grok session sits flush against
the terminal. ANSI slots map onto the palette's own normal/bright pairs.
GrokNight's blue uses `blue` in both slots, as upstream TokyoNight does:
the palette's blue0 is a background blue and only reaches 2.96:1 on
#0a0a0a, which is too dim for ls output.
config.json carried a raw apiKey byte-identical to DEEPSEEK_API_KEY in
~/.reasonix/.env, which config.toml already names properly via
api_key_env -- so the copy was redundant, not load-bearing. Removed it;
`reasonix doctor --json` still reports key_present=true for both
providers and the rest of the report is unchanged.
The remainder of config.json is machine-local state -- a generated
dashboard token, its port, and UI flags -- so ignore it rather than
track it. config.toml stays tracked and holds the portable config.
opencode rejected the config with "Unrecognized key: providers". The
file had both `provider` (opencode's schema: npm + options) and
`providers` (package: "aisdk:..." + settings, some other tool's shape,
left behind by an api-for-cursor script back in July). The Alibaba/Qwen
provider lived only under the rejected key, so it had never actually
reached opencode.
Translate it into the real schema -- package -> npm, settings -> options
at both provider and model level -- rather than dropping it, so those
five qwen models now work. The duplicate cursorapi under `providers` is
dropped: the existing provider.cursorapi is a superset, with four models
plus cost and limit metadata.
The 113-char bailian key moves to secrets/bailian-api-key (0600) and is
referenced as {file:./secrets/bailian-api-key}, which opencode resolves
relative to the config dir -- so no absolute home path, and no shell
export needed on ssh-only boxes. Verified by pointing it at a missing
file and getting "bad file reference".
With the key out, opencode.json can finally be tracked. Ignore the
secrets dir, the stale .bak copies that still contain it, and the
node/bun lockfiles.
`chezmoi apply` on Linux printed "could not regenerate kitty theme
files" every run. GNU stat reads -f as --file-system, so
`stat -f '%Lp' file` prints a block of filesystem info to stdout and
exits non-zero. The `|| stat -c '%a'` fallback then appended the real
answer to that block, and chmod rejected the result, failing the script
under set -e.
Replace the chain with a file_mode() helper in both scripts: try the GNU
form first, since BSD rejects -c cleanly without printing anything, and
accept the answer only if it is octal. Covered by a new case in
tests/test_theme_mode.sh using a stat stub that reproduces GNU's
behaviour; it fails against the old chain.
codex's config.toml held nine live API keys inline under
[mcp_servers.*.env] -- deepseek, gemini, kimi, mimo, qwen, glm, cursor,
an OpenAI key and a Home Assistant token -- so it could not be tracked
as it stood. TOML env tables take literal values only, with no ${VAR}
indirection or env_file, so the keys cannot simply be named there.
Move them to ~/.codex/secrets.env (0600, ignored) and route the four
affected servers through mcp-with-secrets.sh, which sources that file
and execs the real command. Doing it in the wrapper rather than relying
on exported shell vars means it does not depend on how codex handles
environment inheritance, and works on ssh-only boxes with no keychain or
1Password agent, which is why this was preferred over a chezmoi
template.
Adds configs for claude, codex, pi, grok, kimi, kimi-code and reasonix,
and extends .chezmoiignore so credentials, session logs, local state and
.bak files stay out even if a directory is ever added whole.
Held back for still containing live keys: opencode.json (bailian), and
reasonix config.json and .env.
theme-mode is a per-machine preference, and the three *-theme.auto.conf
files are generated from it plus themes/, so tracking any of them made
every machine flag the others' choice. Drop all four from the source
state and ignore them.
That leaves a freshly applied machine with no theme files for kitty to
read, so add run_after_kitty-theme-mode.sh to regenerate them from the
canonical themes. It defaults to `auto`, so a new machine follows its OS
until told otherwise, and it exits quietly where this kitty config isn't
applied rather than failing the run.
Since that script now runs on every apply, including on Linux, make the
permission lookup in both shell scripts fall back from BSD `stat -f` to
GNU `stat -c` and then to 600.
Local drift that was never added: a cursorapi provider pointing at
http://127.0.0.1:8788/v1, plus the formatting pi itself writes. No key
material -- the apiKey fields hold env var names or the local
placeholder.
Captures the current mode. The two generated theme files now hold the
dark theme because the mode is pinned; themes/light.conf still has the
light theme, so `theme light` and `theme auto` restore it.
kitty gives *-theme.auto.conf priority over everything -- includes and
even --override -- and has no option to stop following the OS. So the
only way to start in a chosen mode is to control what those files
contain. Make them generated:
themes/{light,dark,no-preference}.conf canonical, the real themes
theme-mode auto | light | dark
apply-theme-mode.sh writes the three .auto.conf
Under `auto` each appearance keeps its own theme, so kitty follows the
OS as before. Pinned, all three get the pinned theme, so kitty starts in
it whatever the OS says and a config reload no longer resets it.
`theme` now records the mode and reloads instead of calling set-colors,
which is why the setting survives restarts. A bare `theme` records
`auto` rather than pinning when the toggle lands on the macOS
appearance, so nothing is pinned unless it actually differs.
The kitten shim hashes the automatic theme files before running `kitten
themes` and copies whichever changed into themes/, so picking a new
light theme while pinned to dark is kept and applied on the next switch.
Covered by tests/test_theme_mode.sh.
conf.d/kitty_theme.fish is gone: theme-mode is now the source of truth,
so the universal-variable tracker it maintained is redundant.
__kitty_tab_set sent a luminance-picked black/white active_fg, so a
tinted tab's title looked different from a normal one. Send NONE
instead: tab_fg() then falls back to the shared active foreground (the
theme background) while active_bg keeps the per-host tint.
Covered by a new case in tests/test_tab_bar_colors.py matching what
__kitty_tab_set actually sends — host background, no fg override.
a68b138 made draw_tab() derive all four color roles from tab_colors(),
so it stopped reading the per-tab colors that `kitten @ set-tab-color`
sets. The ssh wrapper (__kitty_tab_set) still set them, but the renderer
discarded them and every remote tab drew in the #2e84e6 accent.
Resolve the drawn colors through DrawData.tab_fg/tab_bg on the already
role-substituted title_draw_data: those return the per-tab override when
one is set and the accent roles otherwise. Theme-provided tab colors
still cannot leak in, so the theme-independence fix is preserved.
Extend tests/test_tab_bar_colors.py with the override case; it fails
against the old renderer (got the accent, wanted the host color).
The bare command substitution ran on every shell start regardless of
platform, so Linux/WSL printed "fish: Unknown command: security" at
login — the 2>/dev/null only redirects the command's own stderr, not
fish's command-not-found diagnostic.
Guard with `type -q security`, matching conf.d/codex-github-mcp.fish,
and skip the export when the lookup returns nothing so a missing
keychain item no longer exports an empty GITHUB_PERSONAL_ACCESS_TOKEN.
`theme` switches kitty between the existing dark-theme.auto.conf and
light-theme.auto.conf via `kitty @ set-colors --all --configured`, so it
stays in sync with whatever `kitten themes --light/--dark` selects.
Subcommands: light, dark, auto (hand control back to the OS appearance
via load-config), status.
Tide is resynced by calling __tide_apply_terminal_appearance directly,
so the prompt recolors even if kitty sends no palette-change
notification for a dynamic color change. conf.d/kitty_theme.fish tracks
$fish_terminal_color_theme into $kitty_theme_mode so the toggle still
reads the real state after kitty follows an OS appearance change.
light-theme.auto.conf had no tab colors, which left the dark tab bar on
a light background after switching; add a matching tab style block.
Add a nova 'session' segment (#S) on the right side, styled with the
same colors as the window tabs (#6272a4 bg / #f8f8f2 fg).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Tint the kitty tab background by target host so local vs remote (and
which remote) is visible at a glance.
- __kitty_host_color: explicit color table for known hosts (routers,
resolvers, ryzen/mini, personal cloud, geo VPS) + stable hashed
palette fallback; auto-picks readable fg by luminance
- __kitty_ssh_host: parse target host from ssh/mosh-style argv
- __kitty_tab_set/__kitty_tab_reset: active tab = full host-color bg,
inactive tab = dark theme bg with host-color text; revert on exit
- ssh wrapper + s (kitten ssh) and m (mosh) wired to tint/reset
Also includes unrelated pending dotfile changes (GH MCP PAT from
keychain in fish/zsh, kitty/wezterm font_size 15->14, kitty
colorspace displayp3) committed together at user request.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
