"I Added a /yolo Button to My Local AI Assistant"

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 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.

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

In CliGate, /yolo

flips a conversation-level flag:

/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.

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

.

They say things like:

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.

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:

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.

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.

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:

/yolo

, it stops nagging me for every tiny step/safe

restores it immediatelyThat 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?