Windows marketplace hook latency — interpreter cache
Marketplace/plugin installs run every hook through the bash launcher, which
re-ran full Python interpreter discovery on each invocation — a whole-PATH
walk plus --version probes of Windows Store Python stubs (2 seconds each). Fired
on nearly every prompt and tool call, that repeated discovery is the prime suspect
for the multi-second per-hook latency Windows users have reported.
python-launcher.sh now caches the resolved interpreter, so warm hooks skip
discovery entirely (a cache hit is an -x check + safe-prefix re-validation — no
PATH walk, no stub probing).
- Fail-open + POSIX-neutral. Any cache setup/read/write failure falls through
to the original discovery unchanged, so it cannot regress any platform —
worst case Windows behaves exactly as before. macOS/Linux (already fast) just
re-validate their cached interpreter. - Security-hardened after adversarial review: rejects
..path traversal in
the safe-prefix check, requires cache-dir ownership (-O), removed the
world-predictable/tmpfallback (blocks cross-user cache poisoning), and
re-applies the anti-hijack safe-prefix filter on the cache-read path. - Added the all-users
py.exelocation to the Windows allow-list.
Design note: an all-Node exec-form shim was prototyped and rejected —
measured +82ms/hook (+66%) on macOS because Node adds a full interpreter
cold-start yet still spawns Python (a pure POSIX regression), and Claude Code
hooks.json cannot gate a command by OS. The interpreter cache is the
POSIX-neutral fix.
Complements 5.11.48's native Windows launcher for script installs; this
release targets marketplace/plugin installs.