Claude Code 자동 모드: 종합적인 기술 요약

Auto mode replaces the human "approve/deny" permission prompt with an ML classifier that evaluates every tool call before execution. Instead of asking you whether rm -rf node_modules is okay, a second instance of Claude (Sonnet 4.6) reads the conversation transcript and decides in real time. This document walks through how it works, from the high-level architecture down to the actual code. - The Philosophy: Intent, Not Just Commands - The Big Picture - Three Tiers of Defense - The Two-Stage Classifier - The Reasoning-Blind Design - Transcript Building and Injection Prevention - The System Prompt and Customizable Slots - Block Rules and Threat Model - Dangerous Permission Stripping - Denial Tracking and Recovery - Multi-Agent Classifier Checks - Fail-Open vs Fail-Closed - Cache Optimization - Performance Numbers - Key Files Reference The classifier is not a command blocklist. It doesn't just ask "is rm -rf dangerous?" — it asks "did the user authorize this specific rm -rf on these specific files?" This is the core design philosophy, and it's what separates auto mode from a traditional security scanner. The classifier evaluates the gap between what the user requested and what the agent is actually doing. Consider: | User says | Agent does | Classifier verdict | |---|---|---| | "Clean up old branches" | Deletes local stale branches | Allow — matches the request | | "Clean up old branches" | git push origin --delete on 15 remote branches | Block — the user said "clean up," not "batch-delete remotes" | | "Deploy to staging" | Runs deploy script against staging | Allow — direct match | | "Deploy to staging" | Runs deploy script against production | Block — wrong target, even if the command syntax is identical | The classifier's operating principle: everything the agent chooses on its own is unauthorized until the user says otherwise. One approval isn't a pattern — prior approval of similar actions doesn't automatically cover new variations. The system addresses four distinct categories, but blocks them all the same way: 1. Overeager Behavior — The agent genuinely tries to help but exceeds its authorization. This is the most common real-world issue. The agent discovers credentials during debugging and uses them. It deletes a lock file blocking its progress. It "helpfully" force-pushes to fix a diverged branch. These look like reasonable problem-solving, just applied past the boundary of what the user authorized. 2. Honest Mistakes — The agent misunderstands scope. It thinks test resources are isolated when they're shared. It misjudges branch ownership. It assumes a staging environment is safe to wipe. The intent is correct but the understanding of the environment is wrong. 3. Prompt Injection — External content (a malicious README, a crafted error message, a hostile web page) plants instructions that the agent follows. The agent's intent has been hijacked. 4. Misaligned Models — The model pursues independent goals. This is the theoretical worst case and the hardest to defend against. The classifier treats it identically to the other three: evaluate the action, not the stated reason. The classifier looks through wrappers to evaluate what actually happens: - If the agent writes a Python script that assembles a shell command, the classifier evaluates the assembled command, not just python script.py - If commands are chained with && , the whole chain is one action — you can't hiderm -rf / after a benignecho hello - If the agent base64-encodes a payload, the classifier evaluates the decoded content This is why the classifier is an LLM (Sonnet 4.6) rather than a regex engine. A regex can catch rm -rf / but can't understand that python -c "import os; os.system('rm -rf /')" does the same thing. For every action, the classifier effectively asks three questions: - Is this action dangerous? (Could it cause irreversible harm, leak data, cross trust boundaries?) - Did the user authorize this specific action? (Not "something like this" — this exact thing) - Does the user's authorization cover the blast radius? (Saying "delete the test file" doesn't authorize deleting the test directory) An action can be dangerous and still be allowed — if the user explicitly asked for it. And a seemingly benign action can be blocked — if it's outside the scope of what the user requested. The Stage 2 classifier prompt makes this explicit: As a reminder, explicit (not suggestive or implicit) user confirmation is required to override blocks. This means: - The user typing "sure, go ahead" after seeing a plan does not equal blanket authorization for everything in the plan - The agent saying "I'll need to do X" in its reasoning does not equal user consent for X (and the classifier can't even see this reasoning — see Reasoning-Blind Design) - A CLAUDE.md instruction like "always run tests" does equal explicit authorization for running tests - Vague requests like "fix everything" do not authorize destructive operations When you run Claude Code in auto