What probably matters to youSection of the release
What
--disallowed-tools sets deny rules, which list the tools or tool uses Claude may not use. When starting a cloud-hosted session, it used to be refused outright. It is now passed through for new sessions.
Attaching to an existing cloud session with flags that would change its deny list is refused. The message says the flag "cannot change an existing cloud session, which keeps the deny list it was created with" and tells you to drop the flag, or start a new session with it.
A rule that opens a parenthesis and never closes it, such as Bash(rm *, is refused with its own error instead of being silently dropped. The message asks you to close the parenthesis and run the command again.
The general refusal for restrictions a cloud session cannot enforce now reads "does not enforce these tool restrictions yet" instead of "does not enforce tool restrictions yet".
The new refusal reasons are attach_restriction and deny_rule_unclosed.
Why
If you script remote runs, you can now set a deny list when a cloud session is created. The new errors tell you when a deny rule would not take effect, instead of the rule quietly disappearing.
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed sinceAnthropic's documentation has since written up --disallowed-tools, on Error reference.* Fix the rule at its source, which the full warning names in parentheses: a settings file path, or the flag itself for `--allowed-tools` and `--disallowed-tools`. A `claude-settings-<hash>.json` path that doesn't exist on disk stands for …errorssee the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up --disallowed-tools, on Error reference.