Blog

Kimi Code --yolo and --auto: the mode called yolo is not the riskiest one

Moonshot's CLI kept the word yolo for its middle setting and gave the real skip-everything mode a quieter name. Read the flags carefully before scripting either one.

Quick Answer

Kimi Code has three permission modes. --yolo starts in Ask When Needed: routine edits and commands run, while risky actions, sensitive files and leaving plan mode still ask. --auto starts in Never Ask, which approves everything, including what --yolo would have stopped for. One block survives both: read, write and edit tools cannot touch secret files. Kimi Code has no sandbox. Forkbench adds the credential half: a key used through Vault never enters Kimi's environment.

Three modes, and the names are misleading

Always Ask is the default. Ask When Needed, chosen with --yolo, -y or /yolo, runs routine work and still asks before dangerous commands such as rm -rf or shutdown, before touching files like .env and SSH keys, and before leaving plan mode. Never Ask, chosen with --auto or /auto and added in version 0.5.0, approves everything.

So in Kimi Code, yolo is the safer of the two unprompted modes. The two flags are mutually exclusive, and --yes and --auto-approve are hidden aliases for --yolo, not for --auto, which is easy to get backwards.

One more trap for scripts: a non-interactive run with -p cannot take --yolo, --auto or --plan, and always runs at the Never Ask level.

What each mode still guards

Ask When Needed keeps the dangerous-command guard and the sensitive-file guard. Both can be switched off with dangerous_command_guard = false or the KIMI_CODE_DANGEROUS_COMMAND_GUARD environment variable.

Never Ask drops the prompts for all of them. What it does not drop is the hard block that stops the read, write and edit tools touching secret files, which the documentation says stays in effect regardless of mode. Static deny rules in [[permission.rules]] also apply in every mode, including the forced Never Ask of a non-interactive run.

The edge of that hard block is the same as everywhere else: it covers Kimi's file tools, not a shell command that reads the file or a key already exported into the environment.

Which Kimi CLI this is

Moonshot's original Python kimi-cli repository is archived and replaced by Kimi Code, which ships the same kimi command. Everything here is about Kimi Code. Older guides describing a different flag set are usually describing the archived one.

How this works in Forkbench

Forkbench is a desktop app for running coding agents. Kimi Code runs in it as the kimi command you installed, with your config untouched, and reaches the Thread's notes and board through the fb command on its PATH.

Kimi already guards secret files from its own tools. Forkbench closes the edge of that guard: a key in Vault is used by the command that needs it without the value entering Kimi's environment or any file in the project, so there is nothing for a shell command to read. A Thread can also be locked to a set of folders by the kernel, the sandbox Kimi does not ship.

The limit: a folder lock bounds files, not network requests, and a command you authorise can still use a key against the destination it was bound to.

Related: Yolo mode in every coding agent, compared, Claude Code: what --dangerously-skip-permissions actually skips, Stop a coding agent reading your .env file

Frequently asked

Keep reading

Sources