Kimi Code YOLO Mode: The --yolo Flag, Auto Mode and Safe Use

Kimi Code has a real YOLO mode, and it is one flag: kimi --yolo. Run it and Kimi Code stops asking for approval on file writes and shell commands and just executes. Unlike opencode, where autonomy lives in a config file, Moonshot AI went the same route as Claude Code and Codex: a single switch that turns the prompts off. That switch is genuinely useful and genuinely dangerous, in the same proportions as every other agent's bypass flag. This guide covers what --yolo actually does, how it relates to the other run modes (--auto and --plan), a resume gotcha that silently overrides the mode a session had saved, and the middle path most people miss: pre-approving specific tools with permission rules in config.toml instead of opening everything at once. It also covers the part that matters once the prompts are off: how to keep a full-auto run supervised. Kimi Code is a first-class agent in CodeAgentSwarm, so a YOLO run gets live per-terminal diffs, desktop notifications and searchable history instead of running as a black box.

The short answer: yes, Kimi Code has a YOLO flag

"YOLO mode" is the community nickname for running a coding agent with approvals bypassed. Claude Code has --dangerously-skip-permissions, Codex has --full-auto, and Kimi Code has --yolo. Same idea in all three: the agent stops pausing to ask whether it can write a file or run a command, and just does it.

bash

# Full auto: no approval prompts
kimi --yolo

# Short form
kimi -y

Kimi Code is the terminal coding agent from Moonshot AI, running the Kimi K3 model. If you have not set it up yet, the how to use Kimi Code guide covers install and login. This guide assumes you have it running and want to know how far to open it up.

There are also two hidden aliases, --yes and --auto-approve, that do the same thing as --yolo. They exist so scripts and muscle memory from other tools keep working. Whichever spelling you use, the behavior is identical: every tool call is approved automatically.

Kimi Code ships new releases almost daily and is still pre-1.0, so flags can move. If a flag in this guide does not respond the way you expect, run kimi --help and trust your installed version over any blog post, including this one.

YOLO vs auto vs plan: the three run modes

The --yolo flag is one of three mode switches Kimi Code accepts at launch, and it helps to know where it sits on the spectrum:

Default (no flag). Interactive approval. Kimi Code stops and asks before actions that need permission, and you approve or reject each one.
--plan. Plan mode. The agent works out what it would do and presents the plan instead of charging ahead. Good for scoping a change before letting it touch anything.
--auto. Auto mode. More autonomy than the default without removing every guardrail.
--yolo. Everything is approved automatically. No prompts, no pauses, full speed and full risk.

A sane workflow uses more than one of these. Scope a risky change with --plan, run routine work in the default mode, and save --yolo for tasks where the blast radius is contained: a scratch branch, a throwaway repo, or an isolated worktree.

The resume gotcha: mode flags override the saved session

Kimi Code sessions remember the mode they were running in. When you resume one with kimi --continue or kimi --session <id>, it normally comes back in that saved mode. But if you pass --yolo, --auto or --plan alongside the resume flag, the flag wins and the saved mode is overridden.

This cuts both ways. Resume a careful interactive session with a leftover -y in your shell history and it silently becomes a YOLO session. Resume a YOLO session with --plan and it stops executing. Check which flags are on the command line every time you resume, especially if you lean on shell history to relaunch.

Resuming sessions has its own mechanics (where they live on disk, how to find an old one, how to name them). The Kimi Code conversation history guide covers all of it.

What --yolo can actually do to your machine

With approvals off, Kimi Code runs on a live repo with a real Git history and a real shell. None of these are hypothetical; they are the standard failure modes of any coding agent in full auto, and a single misread instruction is enough:

Git push to the wrong branch. Half-finished work committed and pushed to main, or a force-push over a teammate.
Deleted files and directories. An rm -rf on a path you did not mean, executed without a prompt to catch it.
Irreversible commands. Database drops, docker system prune, anything that cannot be undone once it runs.
Bad dependency installs. A typosquatted package that looked right at a glance, installed and imported before you notice.
Unintended network calls. Production endpoints hit, webhooks triggered, data sent somewhere you did not expect.
Overwritten uncommitted work. Your mid-change files edited underneath you, with no prompt in the way.

One more failure mode is specific to unattended runs: Kimi Code has open issues where a rate-limited or stalled request can leave the session hanging silently instead of erroring out. In an interactive session you notice. In a YOLO run you left alone for an hour, a hung agent looks exactly like a working one from the outside. This is one of the strongest arguments for running full-auto sessions somewhere with real visibility.

The middle path: permission rules instead of full YOLO

Most of the time you do not actually want everything approved. You want the routine stuff (file edits, reads, your test runner) to fly through, while the dangerous stuff still stops. Kimi Code supports exactly that with [[permission.rules]] entries in its config file at ~/.kimi-code/config.toml, which pre-approve specific tools so they no longer prompt, without touching anything else.

That gives you a graded ladder instead of a binary switch: default mode with a few pre-approved tools is dramatically less annoying than stock default mode, and dramatically safer than --yolo. The exact rule syntax is documented in the official Kimi Code docs, and it evolves with the near-daily releases, so check the docs for your installed version rather than copying a snippet from an old post.

For sharper control there are hooks: Kimi Code has a full hook system, configured as [[hooks]] TOML blocks in the same config.toml, with 16 lifecycle events. The one that matters for safety is PreToolUse: a hook script that exits with code 2 blocks the tool call and sends its stderr back as the reason. That lets you write your own guardrails, like blocking force-pushes or protecting a directory, that hold even in YOLO mode.

After editing config.toml, run kimi doctor. It validates the configuration and catches a malformed rule or hook before you find out mid-session. Also worth knowing: hook errors other than exit 2 fail open, so a crashing guardrail script does not block anything. Test your hooks on purpose.

Standing instructions belong in AGENTS.md, the cross-tool instructions convention Kimi Code follows (it does not read CLAUDE.md natively). House rules there, like "never push without asking", reach every session without being re-typed, though unlike a PreToolUse hook they are guidance for the model, not an enforced block.

How to run kimi --yolo safely

The pattern that works is the same one that works for Claude Code and Codex in full auto: contain the blast radius, keep a restore point, and keep your eyes on the run.

Work on a feature branch, never main. If the run goes sideways, you throw the branch away.
Commit before you start. A clean working tree means git checkout . is a one-line undo for anything short of a push.
Use a git worktree for real isolation. A separate worktree gives the agent its own copy of the repo, so even an aggressive run cannot touch the files you are editing. The git worktrees for AI coding agents guide covers the setup.
Keep prompts scoped. "Migrate these three files to the new API" is a safe YOLO task. "Improve the codebase" is not.
Add PreToolUse hooks for your red lines. Force-push, production configs, dotfiles: whatever must never happen, enforce it with an exit-2 hook rather than hoping.

Supervised YOLO in CodeAgentSwarm

The remaining problem is visibility. A YOLO run in a lone terminal window is a black box: you find out what happened when you come back and read the scrollback. CodeAgentSwarm runs Kimi Code as a first-class agent (alongside Claude Code, Codex, Antigravity CLI and opencode) and wraps every terminal with the supervision that full-auto work needs:

Live per-terminal diffs. Watch exactly which files each Kimi Code agent is changing while it runs, not after.
Desktop notifications. Get pinged when an agent finishes or stalls, which also catches the silent-hang failure mode instead of letting it burn an hour.
Searchable history. Audit what a YOLO run actually did after the fact, and resume the session if it stopped halfway.
Several agents side by side. Run one careful interactive Kimi Code terminal and one YOLO terminal on a scratch branch in the same window, and see both at a glance.

If you are heading toward several Kimi Code agents at once rather than one fast one, that is its own topic: see running multiple Kimi Code sessions and the Kimi Code agent swarm guide.

How Kimi Code YOLO compares to the other CLIs

If you run more than one agent, the bypass flags are easy to mix up. The models differ more than the flags do:

Claude Code: --dangerously-skip-permissions, plus granular allow rules in settings. The Claude Code YOLO guide covers it.
Codex CLI: --full-auto and approval modes. Covered in Codex YOLO mode.
opencode: no flag at all; autonomy is config-driven. See opencode YOLO mode.
Kimi Code: --yolo / -y for the full bypass, permission rules and hooks in config.toml for the graded version, and mode flags that override a resumed session's saved mode.

Kimi Code lands closest to Claude Code, which is no accident: its tool set and conventions track Claude Code closely, down to reading the same shared skills directory. The practical consequence is that habits transfer. If you already have a safe YOLO workflow for Claude Code, the same branch hygiene, worktree isolation and supervision carry straight over to kimi -y.

FAQ

Yes, and it is literally called that: kimi --yolo (short form -y) runs Kimi Code with every tool call approved automatically, no permission prompts. The hidden aliases --yes and --auto-approve do the same thing. It is the same idea as Claude Code's --dangerously-skip-permissions or Codex's --full-auto.

They are three run modes. --plan makes the agent propose a plan instead of executing, the default mode asks for approval on permissioned actions, --auto grants more autonomy short of a full bypass, and --yolo approves everything automatically. You can also pass any of them when resuming a session, and the flag overrides the mode the session had saved.

It is as safe as the blast radius you give it. On a feature branch or an isolated git worktree with a clean commit behind you, a scoped YOLO run is a reasonable trade. On main, on a repo with uncommitted work, or with an open-ended prompt, it can push, delete and overwrite without anything stopping it. Contain it, keep a restore point, and watch the diff.

Use permission rules. [[permission.rules]] entries in ~/.kimi-code/config.toml pre-approve specific tools so they stop prompting while everything else still asks. That usually removes most of the friction without opening shell and Git actions. Run kimi doctor after editing the config to validate it.

Yes, with hooks. Kimi Code supports [[hooks]] TOML blocks in config.toml across 16 lifecycle events, and a PreToolUse hook that exits with code 2 blocks the tool call with your stderr message as the reason. That is an enforced guardrail, unlike AGENTS.md instructions, which are guidance the model follows but nothing enforces. Note that hook scripts that crash with any other error fail open.

Kimi Code is a first-class agent in CodeAgentSwarm, so you can run YOLO sessions inside it with supervision around them: live per-terminal file diffs, desktop notifications when an agent finishes or stalls, dynamic terminal titles, and searchable history to audit what a run did. Running full auto with visibility is the whole point.

Run kimi --yolo without flying blind. CodeAgentSwarm runs Kimi Code as a first-class agent, with live per-terminal diffs, desktop notifications and searchable history keeping every full-auto run honest.

Try CodeAgentSwarm

How to Run Multiple Codex CLI Sessions at Once

Yes, you can run multiple Codex CLI sessions at once. Each Codex session is its own process, so two or more of them can work on different tasks in the same repository at the same time without sharing context.

Read guide

View all guides