How task-scoped approvals turned my AI assistant from annoying to seamless

Imagine asking a coworker to fetch a document from the server. Each step—walking to the server room, unlocking the door, locating the file, and returning—would require pausing for approval. While safety is paramount, this level of interruption quickly turns a five-minute task into an hour of clicking through prompts.

That’s exactly what happened with my local AI coding assistant. Every minor action—checking Python’s presence, finding a PDF converter, executing the tool, or reading the output—triggered a fresh confirmation. What began as a protective feature became an unusable workflow.

Why granular approvals backfire in multi-step tasks

Approval prompts are essential for local AI assistants. They prevent tools from writing files, opening applications, or modifying the desktop without oversight. The core issue isn’t the safety mechanism; it’s how the system treats each tool call as a standalone event.

Real-world tasks rarely fit into single actions. Reading a PDF might involve:

• Detecting installed Python version
• Searching for a compatible converter
• Running the conversion
• Parsing the output text
• Generating a summary

Asking for confirmation before each step disrupts the user’s intent. Instead of evaluating risk, the user starts habitually clicking through prompts—effectively training the system to ignore the safety guardrails.

Shifting from tool-level to task-level trust

The breakthrough came when I redesigned the approval flow to respect the user’s original intent. After the first tool execution in a conversation receives explicit approval, the system flips a conversation-level flag. Subsequent actions within the same task proceed without repeated interruptions.

Here’s how the updated flow works:

conversation.flag_task_approved = True

The assistant continues executing, using real tool results as context for the next step. This eliminates redundant approval loops while maintaining security. Crucially, users retain full control through an escape hatch: the /safe command reverts the conversation to strict per-action confirmation mode.

Preserving context to prevent approval loops

A subtle but critical detail is how the system communicates between steps. When a user approves an action, the assistant doesn’t just receive a generic "confirmed" signal. It’s explicitly told:

• The previous tool call was approved
• It executed successfully
• It produced real output

This prevents the assistant from asking the same question twice or losing track of the task’s progress. The workflow now feels cohesive rather than fragmented:

• Request approval once for task boundaries
• Execute the first step
• Continue using real results as context
• Only interrupt if the user triggers strict mode or a new boundary appears

Fixing mixed-language approval prompts

The continuation system introduced another challenge. System-generated messages were authored in English, but some users initiated tasks in Chinese. The assistant occasionally misinterpreted these system prompts as user input, switching subsequent approvals to English.

This created jarring workflows where initial confirmations appeared in Chinese, but follow-up prompts switched to English. The fix was straightforward: system-authored continuation messages no longer influence reply language. The assistant now checks the most recent genuine user message before selecting the response language.

Small details like this matter when building multi-step tools. They transform an experience from "the system is reacting to its own plumbing" to "the assistant is tracking my intent."

The approval philosophy I’m adopting

I don’t believe local AI assistants should default to all-or-nothing permission models. The most effective approach balances security with usability through task-scoped trust:

• Request confirmation before crossing meaningful boundaries
• Maintain approval context for the current task
• Provide an obvious way to escalate to strict mode
• Prevent system messages from masquerading as user intent

This philosophy now shapes approval handling in CliGate, the local control plane I use for Claude Code, Codex CLI, Gemini CLI, desktop automation, channels, and model routing. The project remains open source, available for others to adapt or extend.

If you’re building local AI agents, how do you balance safety and efficiency in your approval systems? Is your approach per-tool, per-task, per-session, or something more nuanced?