Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.247 ·

Stricter vetting of hooks forwarded to a cloud session

Hooks forwarded to a cloud session are vetted harder, and refused if their program lives somewhere the session can write.

You'll notice New Features
JSON All of v2.1.247
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
Cloud SessionsArea: what it touches
New FeaturesKind: in v2.1.247,
What probably matters to youSection of the release
What

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.

Details
  • #! parsing understands /usr/bin/env, including its -S option; an interpreter that is a relative path, contains .., is env carrying options, cannot be located, or resolves into somewhere the session can write holds the hook with reason interpreter_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_DIR environment variable is held with reason loads_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_PREFIX that 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_PREFIX is 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 ~/.claude and ~/.config are read; both report reason: "unpinned_command" and suggest marking the hook cloud: "device".
  • All of this applies only to cloud sessions that register device hooks, started with claude --cloud, which still require stored consent through the /hooks command and a bound cloud session; there is no separate flag, and within that path these checks always run.
Evidence

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.

See this entry in the whole of v2.1.247 →

Feedback