Blog
Crush --yolo: the yolo mode that still will not run curl
Crush's yolo mode approves everything the permission system would have asked about. A second list, written into the bash tool itself, was never part of that system.
In Charm's Crush, --yolo or -y, or ctrl+y in a session, auto-accepts every permission request. It cannot touch Crush's banned-command list, which lives inside the bash tool and refuses curl, wget, ssh, scp, sudo and dozens more in every mode. Crush has no sandbox, so everything not on that list runs as you. Forkbench adds the missing wall and keeps keys out of reach: a key used through Vault never enters Crush's environment.
Two lists that never meet
Crush's permission system asks before tools act. --yolo short-circuits it: the first thing a permission request checks is whether yolo is on, and if it is, the answer is yes. In a session, the command palette's Toggle Yolo Mode and ctrl+y do the same.
The banned-command list sits somewhere else entirely, inside the bash tool's command parsing. It refuses network tools like curl and wget, remote access like ssh and scp, privilege changes like sudo and su, package managers, and system tools such as mount and systemctl. Because the permission system never sees those commands, yolo mode cannot approve them. The maintainers declined a request to make the list configurable.
That is an unusual and useful design. The commands most likely to send something off the machine are refused outright, whoever is watching.
What the list does not cover
A banned list is a list, and anything not on it runs. A script in the repository that makes its own HTTP request, a language runtime called with a one-line fetch, or a test that reads a key from the environment are all ordinary commands to Crush.
The safe-command shortcut is the other half to understand. ls, pwd and read-only git commands skip the prompt even without yolo, as long as there are no shell metacharacters. It is a convenience, not a security control, and Crush does not present it as one.
Crush has no sandbox, and its documentation notes that it runs with full shell privileges before yolo is even considered. Yolo cannot be saved in config; it is per invocation.
How this works in Forkbench
Forkbench is a desktop app for running coding agents. Crush runs in it as the crush command you installed, with your config untouched, and reaches the Thread's notes and board through the fb command on its PATH.
The banned list blocks the obvious ways out. What Forkbench adds covers the rest. A key in Vault is used by the command that needs it without the value entering Crush's environment, so a script that is not on any list has no token to send. And a Thread can be locked to a set of folders by the kernel, the boundary Crush never had, inherited by every process it starts.
The limit: a folder lock bounds files, not the network, which is why the key not being in the process is the part that matters.
Related: Yolo mode in every coding agent, compared, Claude Code: what --dangerously-skip-permissions actually skips, What a child process inherits
Frequently asked
How do I enable yolo mode in Crush?
Start with crush --yolo or -y, or toggle it in a session with ctrl+y or the command palette's Toggle Yolo Mode. It cannot be saved as a default in config.
Why won't Crush run curl even in yolo mode?
curl is on Crush's banned-command list, which is enforced inside the bash tool rather than by the permission system. Yolo mode only skips permission prompts, so it cannot approve a banned command.
Can I change Crush's banned commands?
No. The list is hardcoded, and a request to make it configurable was closed without adding an override.
Does Crush have a sandbox?
No. Crush runs commands in your shell with your user's permissions. The banned list stops specific commands; it is not a boundary around the ones it allows.