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.
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.
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.
