Kiro CLI --trust-all-tools: what trusting everything removes, and what Kiro added next to it

Trust, per tool or all at once

By default Kiro trusts reading files and prompts before shell commands, file writes and AWS calls. /tools shows the current state, /tools trust and /tools untrust change one tool, and /tools trust-all trusts everything. The old /acceptall still works as an alias.

--trust-all-tools does the same from the command line, and --trust-tools takes a list such as shell,write if you want to trust two tools and keep the rest asking. For something that lasts, an agent's allowedTools list and its toolsSettings, with regex rules for commands and globs for paths, are the durable versions.

One thing to know for CI: --no-interactive without a trust flag fails the moment a tool needs approval, so unattended runs effectively require choosing what to trust up front.

Deny still wins

Trust removes the question, not the rules. In Kiro, a deny is evaluated before trust-all, so a command your config refuses stays refused with every tool trusted. The current permissions.yaml format takes deny, ask and allow per capability, and --trust-all-tools works as a session override on top of it rather than a replacement for it.

Kiro does not ship any deny rules by default, so this protection only exists if you write it.

The sandbox is new, separate and off

Kiro CLI 2.31, released on 13 October 2026, made a local command sandbox available to every V3 user: Seatbelt on macOS and bubblewrap on Linux, controlling both filesystem and network. It is off by default.

Kiro's documentation describes permissions and sandbox as sequential, not coupled. Trusting all tools does not switch the sandbox on, and does not switch it off. If you want trusted tools inside a wall, you enable the wall yourself.

How this works in Forkbench

Forkbench is a desktop app for running coding agents. Kiro runs in it as the kiro-cli you installed, with your agent configs untouched, and reaches the Thread's notes and board through the fb command on its PATH.

Kiro is the one agent here that can hold AWS credentials as a first-class tool, which is exactly why the credential half matters. A key in Vault is used by the command that needs it without the value entering Kiro's environment, so trusting every tool does not mean trusting every tool with your keys. A Thread can also be locked to a set of folders by the kernel, which holds whether or not Kiro's own sandbox is on.

The limit: credentials Kiro reads from your own AWS profile are outside what Vault brokers, so scope that profile as tightly as you would for any automation.