Nine providers' env overrides do not invalidate their cache (undeclared in PROVIDER_ENV_VARS)

[therickfactr]

Found while scoping #899 Tier 2. Filing separately because it is a distinct defect from the probeRoots() campaign, though it is the same silent-wrong-numbers family as #874.

Summary

Nine providers honor an environment variable that changes where discovery looks, but that variable is not declared in PROVIDER_ENV_VARS. computeEnvFingerprint() hashes only the declared list, so changing the override does not invalidate the provider's cache section. CodeBurn keeps serving sessions parsed from the old root, and reports nothing from the new one, with no diagnostic anywhere.

Repro

import { computeEnvFingerprint } from './src/session-cache.js'

delete process.env['KIRO_HOME']
const before = computeEnvFingerprint('kiro')
process.env['KIRO_HOME'] = '/tmp/kiro-a'
const after = computeEnvFingerprint('kiro')
console.log(before === after)   // true  <-- should be false

Run across the affected set, with codex as a control (it declares CODEX_HOME and behaves correctly):

kiro           KIRO_HOME            fingerprint UNCHANGED  <-- stale cache
grok           GROK_HOME            fingerprint UNCHANGED  <-- stale cache
kimi           KIMI_SHARE_DIR       fingerprint UNCHANGED  <-- stale cache
mux            MUX_ROOT             fingerprint UNCHANGED  <-- stale cache
mistral-vibe   VIBE_HOME            fingerprint UNCHANGED  <-- stale cache
zerostack      ZS_DATA_DIR          fingerprint UNCHANGED  <-- stale cache
codebuff       CODEBUFF_DATA_DIR    fingerprint UNCHANGED  <-- stale cache
goose          GOOSE_PATH_ROOT      fingerprint UNCHANGED  <-- stale cache
crush          CRUSH_GLOBAL_DATA    fingerprint UNCHANGED  <-- stale cache
codex          CODEX_HOME           fingerprint CHANGES  (ok)

goose and crush declare only XDG_DATA_HOME, so they are partially covered — their tool-specific override is the one that goes unnoticed. The rest declare nothing at all.

Why it matters

The user-visible symptom is the #874 shape again: numbers that are quietly wrong with no signal. Point KIRO_HOME at a second profile and the previous profile's sessions keep being reported as if nothing changed. Because the cached section is considered valid, even a fresh run does not re-derive it — the staleness persists until an unrelated parse-version bump happens to clear it.

Adjacent, lower severity

Several providers also read platform path vars that are undeclared, so the same staleness applies when they change: claude and copilot (APPDATA / LOCALAPPDATA, XDG_CONFIG_HOME), ibm-bob and open-design (APPDATA), kilo-code (XDG_DATA_HOME). These move far less often than a deliberate override, so they are worth fixing in the same pass but are not the urgent part.

Suggested fix

Declare the missing variables in PROVIDER_ENV_VARS. It is one line per provider, and the entry is already the mechanism — no new machinery.

Two notes for whoever takes it:

• This will change those providers' fingerprints once, forcing a single re-parse for existing users. That is correct and unavoidable — their cached sections were computed under a fingerprint that did not describe them — but it should be called out in the changelog rather than arriving as a surprise.
• A test asserting that every process.env read inside src/providers/*.ts appears in that provider's PROVIDER_ENV_VARS entry would stop this recurring. The check is cheap and would have caught all nine.

Happy to take this alongside the #899 Tier 2 batches if you want it in one pair of hands, or leave it for someone else — no ownership claim either way.