Hooks forwarded to a cloud session are vetted harder, and refused if their program lives somewhere the session can write.
What's wrong with this entry?
Forwarding this machine's hooks to a cloud session now goes through a fuller admission path that resolves each script's interpreter from its #! line, holds back scripts that read code or data out of the checkout, drops a shell prefix it cannot trust, and trims PATH entries it cannot resolve locally. Hooks whose program resolves somewhere the cloud session can write are refused at call time rather than served. The single generic notice about a hook not being pinnable is replaced by two that say which condition applied.
#!parsing understands/usr/bin/env, including its-Soption; an interpreter that is a relative path, contains.., isenvcarrying options, cannot be located, or resolves into somewhere the session can write holds the hook with reasoninterpreter_unvouched, described as an interpreter this machine cannot vouch for.- A script sitting outside the checkout that sources relative files, names the checkout, or reads the
$CLAUDE_PROJECT_DIRenvironment variable is held with reasonloads_from_reach; the usual/dev/*paths are exempt from this check. - Both holds can be overridden by marking the hook
cloud: "device"in your hook settings. - If an interpreter name resolves to a file the cloud session can write, the served call is refused and recorded with the telemetry outcome
in_reach_refused. - A
CLAUDE_CODE_SHELL_PREFIXthat is unreadable or writable by the session is discarded, the hook runs unwrapped, and a warning is emitted. - A hook that would run wrapped in
CLAUDE_CODE_SHELL_PREFIXis not pinned, because the wrapper rather than the script decides what actually runs, and a script under a dot-directory is not pinned because only~/.claudeand~/.configare read; both reportreason: "unpinned_command"and suggest marking the hookcloud: "device". - All of this applies only to cloud sessions that register device hooks, started with
claude --cloud, which still require stored consent through the/hookscommand and a bound cloud session; there is no separate flag, and within that path these checks always run.
interpreter_unvouched: "an interpreter this machine cannot vouch for", loads_from_reach, prefix-unwrapped, would run wrapped in your CLAUDE_CODE_SHELL_PREFIX
Strings lifted out of the shipped bundle, so the claim above can be checked against them.