Aider --yes-always: what it says yes to, and why there is no sandbox behind it

What --yes-always confirms

Aider asks before a handful of things: adding files to the chat, creating new files, and running shell commands it suggests after an edit, such as a test run or a package install. --yes-always says yes to all of them.

The flag was called --yes until version 0.59.0, and --yes still works. It can also be set with the AIDER_YES_ALWAYS environment variable or yes-always: true in .aider.conf.yml, which makes it apply to every session without anyone typing it.

The setting that matters more than the flag

--suggest-shell-commands is on by default. It decides whether Aider offers to run commands at all. Turn it off with --no-suggest-shell-commands and --yes-always has nothing dangerous left to approve: it confirms file additions and edits, which Aider commits to git anyway.

That is the useful way to think about Aider. Edits are the cheap half. Auto-commits are on by default, and dirty files are committed before Aider touches them, so every change is one git revert away. Shell commands are the expensive half, and they are a separate switch.

If you want Aider to run your tests without asking, --auto-test with a --test-cmd you chose is narrower than approving whatever it suggests.

Nothing is sandboxed, with or without the flag

Aider has no sandbox anywhere in its source or documentation. A command it runs, approved by you or by --yes-always, runs in your shell with your files, your network and your environment.

So the flag changes who decides, not what the decision can reach. A key exported in your shell profile is in reach of every command Aider runs, and auto-commits do not help with that, because a credential that was sent somewhere is not something git can revert.

How this works in Forkbench

Forkbench is a desktop app for running coding agents, and Aider runs in it as the aider command you installed, with your .aider.conf.yml intact. It reaches the Thread's notes and board through the fb command on its PATH.

It adds what Aider leaves out. A key in Vault is used by the command that needs it without the value entering the shell Aider runs in, so a suggested command approved by --yes-always has no token in its environment to send. A Thread can be locked to a set of folders by the kernel, which gives the shell commands a wall the edits already had in git.

The limit: the folder lock is about files, not the network. Keeping the key out of the process is the part that does not depend on that.