A hook that rewrites commands fails every command when its binary is missing

I run a hook that rewrites Claude Code’s Bash calls through a token-optimizing CLI proxy. git status becomes rtk git status, output gets compressed, tokens get saved. Nice little system, right up until it isn’t.

Today every single shell command failed:

/bin/bash: line 3: rtk: command not found

The hook fires before the command runs, rewrites it, and the rewritten binary didn’t exist in this environment. The hook itself never errors. It does its job perfectly. The command it produces is what dies, so there’s no hook failure to see in the logs, just a session where ls suddenly doesn’t work. That misdirection is what cost me twenty minutes: I went looking for a bug in the hook, and the hook was fine.

Two lessons:

Rewrite hooks need an existence check. One guard fixes the whole class of failure:

command -v rtk >/dev/null || { echo "$ORIGINAL_CMD"; exit 0; }

Fall through to the original command when the proxy is missing. Degraded, not broken.

Claude Code routes around damage. The interesting part: Claude noticed the pattern after two failures and started wrapping commands in bash -c '...', which the hook’s matcher didn’t rewrite, then kept working the entire session with that workaround. It also wrote the incident into its project memory, so the next session starts with the workaround already known.

Fix the hook anyway. A workaround in the agent’s memory is a patch, not a repair.

Next step

Hooks are worth the risk when they are scoped well. Session goals with Stop hooks shows one that earns its place. If you want a Claude Code setup whose hooks fail safe, that is part of the Claude Code workflows I build. Book a call.