I like local AI assistants that ask before they do risky things.

I do not like approving the same task six times in a row.

That was the failure mode I kept hitting while working on CliGate. A normal task would start with one reasonable command, then another, then another, and every tiny step wanted a fresh confirmation.

So I added a blunt but useful switch:

/yolo

It sounds reckless, but the real goal was the opposite: make the assistant feel faster without training me to click through meaningless approval spam.

The bad version of safety was too chatty

The old loop looked safe on paper:

assistant picks a mutating tool
-> asks for confirmation
-> user approves
-> one tool runs
-> assistant continues
-> next tiny tool asks again

That is technically correct.

It is also miserable in practice.

A real task is rarely one tool call. Reading a document, checking a project, or sending a result through a channel usually means several small steps in a row. If every step interrupts the user, the approval system stops communicating risk and starts communicating friction.

That is when safety UI turns into background noise.

/yolo made the approval scope match the user's intent

The fix was not "remove approvals." It was "remember what the user actually meant."

In CliGate, /yolo flips a conversation-level flag:

• later mutating tool calls in the same conversation auto-approve
• the assistant stops asking for every tiny follow-up step
• the user can turn strict mode back on with /safe

Under the hood, the flag lives on the conversation metadata as assistantCore.autoApproveTools, and both web chat and channel conversations read the same source of truth.

That detail mattered because I did not want one behavior in the web UI and a different one in DingTalk or Feishu.

Natural language mattered as much as the slash command

The more interesting part is that users do not always type /yolo.

They say things like:

• "后续都同意"
• "不要再问我了"
• "直接执行"
• "from now on, just do it"

So I added sticky-approval phrase detection too.

That means the assistant can recognize conversation-wide consent from normal language, not only from a command. But it still treats denial phrases separately, so "我不同意" does not accidentally enable auto-approve just because it contains the word "同意".

This turned out to be one of those small pieces of product logic that matters more than the model prompt.

I still kept a real high-risk boundary

The trap with a feature named /yolo is obvious: if everything gets auto-approved, then safety is fake.

So I kept one hard rule.

Routine local work can flow through auto-approve mode, but genuinely destructive or external actions still need a fresh explicit confirmation.

That means things like:

• deleting files or directories
• overwriting data in a destructive way
• publishing outward
• sending messages to other people or other conversations
• submitting forms

still stop and ask.

That boundary is what makes the mode usable. The assistant can stop being noisy about low-level execution steps while still pausing when the consequence is actually irreversible or external.

One confirmation can now cover a whole batch

I also found a second bug while fixing this.

Sometimes one pending confirmation represented multiple queued tool calls. Historically, approving it only executed the first one, which silently dropped the rest.

The confirmation service now expands a pending action into all captured tool invocations and runs each of them in order. One approve means the whole batch gets executed, not just item one.

That sounds like an implementation detail, but it changes user trust a lot. If the UI says "confirmed," users expect the intended action to finish, not partially disappear.

The result feels less magical and more honest

My favorite part of this change is that it did not make the assistant feel more autonomous.

It made it feel more aligned.

The assistant now behaves closer to how a human collaborator would interpret the conversation:

• if I said "just continue," it continues
• if I said /yolo, it stops nagging me for every tiny step
• if the next move is truly risky, it still pauses
• if I want strict mode back, /safe restores it immediately

That balance is what I want from a local control plane: not maximum freedom, not maximum ceremony, just the right amount of friction in the right place.

CliGate is the open-source local control plane I use to route Claude Code, Codex CLI, channels, desktop control, and assistant workflows through one place: CliGate.

If you are building local agents, where do you draw the line between approval memory and real safety boundaries?