What probably matters to youSection of the release
What
The help text for the --trust-workspace flag now documents a second, stricter enforcement mode. Setting --trust-workspace (or its environment variable) to false now triggers this stricter gate: permission grants committed to the repository's own settings (via permissions.allow) are dropped, with a warning like "Ignoring N permissions.allow" printed to the terminal. Instead, such grants have to live in the host machine's own settings.json, not the repo's.
Why
This stops a checked-out repository from being able to grant itself extra tool permissions just by having them committed to its settings files. Anyone relying on repo-committed permissions.allow entries needs to move those grants to their local settings.json if they set --trust-workspace to false.
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.
Added sinceA small documentation edit on Run Claude Code programmatically touched a line naming permissions.allow after this was published.* **`dontAsk`**: Claude Code denies every call that would otherwise prompt, which is useful for locked-down CI runs. Actions that need no approval in Manual mode still run, such as file reads in your working directories and the [read-only …headlesssee the edit
Confirmed sinceAnthropic's documentation has since written up permissions.allow, on All settings.| Lists | Combines entries from every source | [`permissions.allow`](#permissions-allow), [`sandbox.network.allowedDomains`](#sandbox-network-alloweddomains), and other list keys |settings-referencesee 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 permissions.allow, on All settings.
