Add a safer, classifier-backed Auto permission mode

What feature would you like to see?

I’d like Kimi Code’s Auto mode to use a separate classifier to decide whether a tool call is safe to run without confirmation, similar to Claude Code’s Auto mode.

At the moment, Auto mode appears to approve tool calls unconditionally. That makes it useful for unattended tasks, but in practice it feels very close to YOLO. There isn’t much of a middle ground between approving actions manually and allowing everything.

The behavior I have in mind is that existing permission rules would still run first. Straightforward actions such as reading files, editing files inside the workspace, or running tests could continue automatically. Actions that are destructive, affect resources outside the project, interact with production systems, or do not clearly follow from the user’s request could be checked by a lightweight classifier before execution.

When the classifier is confident that the action is safe and relevant, Kimi Code could proceed normally. When it is uncertain, it could ask for confirmation instead of failing open. YOLO would remain available for users who explicitly want to bypass these checks.

This would make the distinction between the modes clearer: Manual asks for approval, Auto works autonomously with a safety check, and YOLO skips approval checks entirely.

I think this would make long-running tasks much easier to trust without introducing prompts for every routine command.

Additional information

Claude Code’s Auto mode is the closest example of the behavior I’m describing.

I found a few related issues, including #1874 about the Auto and YOLO descriptions, #800 about applying authorization policies through ACP, and #1326 about allowing hooks to participate in approval decisions. I don’t think any of them covers adding a built-in classifier for Auto mode itself.

This could either replace the current Auto behavior or be introduced as a separate mode to avoid changing existing workflows. I’d be interested in helping with an implementation after the expected behavior is agreed on.

I would also say that the existing naming for YOLO and Auto modes are somewhat confusing. YOLO sounds like the most dangerous option, and Auto actually sounds like a safe option with implied safety checks, but in reality it's the reverse - Auto = bypass ALL permissions, and YOLO at least still ask you some questions. I think Codex / Claude Code's namings are much clearer: Bypass permissions, Auto, and Manual.

The issue does not name implementation files, tests, or entry points. First trace the current Auto, Manual, and YOLO permission flow, then review related issues #1874, #800, and #1326. Done requires an agreed classifier-backed safety policy, confirmation behavior for uncertainty, and tests covering the mode distinctions.