A Command Is Judged by What It Will Actually Do
Whether a command needs your approval should depend on what it does when it runs, not on how it reads. Warden's pre-release verification tightened that rule, and the commands an agent runs no longer carry Warden's own keys.
Most of what a coding agent does is run commands. Reading a file, listing a folder, checking what changed in git: these are routine, and a request for approval on every one of them would teach an operator to stop reading requests. So Warden lets read-only commands through and stops for the ones that change something. That only works if Warden reads a command the same way the shell that runs it will.
Read the way it will run
On some systems, the shell that runs an agent’s commands follows different rules from the ones a command check usually assumes. Warden’s pre-release verification on such a system found commands that looked like harmless reads under the usual rules but would delete a file under the shell that actually runs them, and Warden had let them through without asking. That is fixed. There, a command that uses syntax only that shell understands is no longer treated as a read, whether the session is in its default mode or planning, and it stops for a decision. Ordinary chained commands are still judged as a chain, so routine work does not turn into a stream of questions.
On those systems, a program a command names without a path is never picked up from the project folder, so a file planted in a repository cannot stand in for the real tool, and batch files are refused.
Stopping means stopped
On every system, stopping a command or letting it time out now ends everything that command started, not just the first process it launched. Saying stop leaves nothing behind still working on the task you stopped.
Your keys stay with Warden
The commands an agent runs, and the hooks a project defines, no longer inherit the credentials Warden uses to reach its model providers. Everything else in your environment still passes through, so git and your build tools keep working. A project whose own tests call those services can be given the credentials on purpose. Warden also masks credentials in every log it writes.
One rule, from the folder to the command
This is the same boundary as what a cloned repository can do before you trust it, one step further in. What an agent’s environment can do should be decided by you, not by whatever happens to be lying in the folder, and a permission rule only means something if it describes what the command will really do on the system that runs it.
Warden is a working proprietary development build. Supported platforms, permission modes, and command behavior will be stated with its public release.
Was this useful?