Claude Code의 확인 프롬프트를 줄이면서도, 위험한 조작은 통과하지 않도록 하는 설정입니다. 1개월 정도 운용해 본 결과, 확인 작업이 격감하였고 확인 피로로 인한 실수도 줄었습니다.

settings.json

의 전문과 PreToolUse 훅(hook) 스크립트를 올립니다. 사용자 이름 등 환경에 의존하는 부분은 가려두었지만, 그 외에는 그대로 작동하는 형태입니다. 위에서부터 읽을 필요는 없으니, 필요한 부분만 복사해서 가져가세요.

먼저, 이 설정에서 가장 중요한 3줄을 적어둡니다.

"defaultMode": "auto", // 일상적인 확인을 띄우지 않음
"autoAllowBashIfSandboxed": true, // 샌드박스 내부라면 Bash도 확인 없이 실행
"failIfUnavailable": true // 샌드박스를 사용할 수 없다면 실행하지 않음

3번째 줄이 없으면, 샌드박스가 조용히 해제된 상태에서 자동 실행이 계속됩니다. 1번째 줄과 3번째 줄은 세트입니다.

{
"env": {
"CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": "1"
...

이하, 판단이 들어간 부분만 보충하겠습니다.

allow는 「읽기·찾기·변환·테스트」 단계까지로 제한했습니다. cat, grep, find, sed, awk, jq, git status, git diff, npm test, phpunit, phpcs 등. 여기에 확인 프롬프트가 떠도, 읽지 않고 통과시킵니다.

그 대신, 외부로 나가는 경로만 차단하고 있습니다.

"Bash(curl:*)", "Bash(wget:*)", "Bash(nc:*)"

sed로 파일을 가공하는 것은 허용하지만, curl로 전송하는 것은 허용하지 않습니다. 읽기 권한과 반출 경로를 분리해서 생각합니다.

Bash(tar -tf:*)만 허용하는 것도 같은 발상입니다. -t는 내용물을 목록화할 뿐이라 안전하지만, -x는 압축을 풀어 파일을 작성합니다. 서브 커맨드 단위로 끊을 수 있는 곳은 끊습니다.

"ask": [
"Bash(svn commit:*)",
"Bash(svn ci:*)",
...

확인을 요청하는 것은, 외부에 공개되어 취소할 수 없는 조작뿐입니다.

WordPress.org의 SVN에 커밋하면, 그 순간 기존의 모든 사용자에게 릴리스가 배포됩니다. 취소할 수 없습니다. 자신에게 가장 영향이 큰 조작이 이것이기에, 이 부분만큼은 반드시 멈추도록 설정했습니다.

목적은 수를 줄이는 것입니다. 확인이 4개뿐이므로, 떴을 때 읽게 됩니다. 수가 많아지면 확인은 신호가 아니라 노이즈가 됩니다.

deny 리스트에서, 가장 먼저 넣어야 한다고 생각하는 것은 이것입니다.

"Bash(wp eval:*)",
"Bash(wp eval-file:*)",
"Bash(wp shell:*)"

wp eval은 임의의 PHP를 실행합니다. 즉, wp db drop을 deny에 넣어도, wp eval이 통과되면 똑같은 일을 할 수 있습니다. 범용적인 우회로를 막지 않으면, 개별적인 deny는 의미가 없습니다.

같은 이유로, 설정 자체의 편집도 막아두었습니다.

"Edit(~/.claude/settings.json)",
"Edit(~/.claude/hooks/**)",
"Edit(**/.git/hooks/**)"

가드레일을 지키기 위한 가드레일입니다.

git 계열에서 deny로 설정한 것은, 이력이나 추적되지 않은 파일이 삭제되는 것으로 한정했습니다.

"Bash(git clean:*)", // 추적되지 않은 파일이 삭제됨
"Bash(git reset --hard:*)", // 변경 사항이 삭제됨
"Bash(git push --force:*)", // 원격 저장소의 이력이 삭제됨
...

git commit이나 git push (force 없음)는 allow입니다. 여기를 막으면 일상적인 작업이 돌아가지 않습니다. 막는 것은 되돌릴 수 없는 것뿐입니다.

"enabled": true,
"autoAllowBashIfSandboxed": true,
"failIfUnavailable": true

autoAllowBashIfSandboxed

autoAllowBashIfSandboxed가 확인 절감을 위한 핵심이며, failIfUnavailable은 그 안전장치입니다. 후자를 false로 설정하면, 샌드박스(Sandbox)를 사용할 수 없을 때 샌드박스 없이 자동 실행됩니다. 이는 가장 위험한 상태이므로 반드시 true로 설정해야 합니다.

"excludedCommands": ["docker", "git", "gh"]

솔직히 말하면, 이것은 타협입니다. git과 gh는 인증 정보와 외부 통신을 사용하기 때문에 샌드박스 내부에서는 제대로 작동하지 않습니다. 억지로 포함시키려다 보면 결국 샌드박스 자체를 끄게 됩니다.

그래서 이 세 가지는 외부로 빼고, 권한(permissions)과 후크(hook)로 제어하는 방식을 택했습니다. 하나의 계층에서 모든 것을 지키려 하지 않겠다는 결단입니다.

"strictAllowlist": true

프라이빗 레지스트리(Private Registry)가 없으므로, 공개 레지스트리 이외를 가리키는 설치는 이상 징후입니다. 따라서 허용 목록(Allowlist)으로 고정할 수 있습니다. 이 부분은 환경에 따라 달라지므로, 자신의 의존성(dependency) 취득처에 맞춰 수정하십시오.

{ "path": "~/.subversion/auth", "mode": "deny" }

WordPress.org의 배포가 SVN 방식이므로, 이곳을 읽을 수 있으면 릴리스(release)를 수행할 수 있습니다. .ssh나 .aws와 나란히, 가장 먼저 차단해야 할 장소였습니다.

~/.claude/hooks/protect-plugin-dirs.sh에 두고 실행 권한을 부여합니다.

#!/usr/bin/env bash
#
# protect-plugin-dirs.sh — PreToolUse(Bash) guard.
...

fail-open 방식으로 구현했습니다. jq가 없거나 JSON이 깨져 있더라도 허용합니다. 가드(guard)의 버그로 인해 세션 전체가 중단되면, 아마 가드 자체를 제거하게 될 것이기 때문입니다. 외곽에 샌드박스와 권한(permissions)이 있으므로, 이 계층은 지나치게 방어적으로 설계하지 않는다는 판단입니다.

rm -rf .의 .을 대상으로 포함했습니다. 작업 중인 디렉토리 자체가 플러그인 폴더이므로, .의 삭제는 곧 폴더의 소실로 이어집니다. 릴리스 빌드(release build)를 실수로 날려버리지 않도록 합니다. 패턴의 끝을 '슬래시, 공백, 행 끝'으로 한정했기 때문에, prime-cache/는 매칭되지만 prime-cache.zip은 매칭되지 않습니다. 빌드 시의 rm -f prime-cache.zip은 통과합니다. 너무 과하게 막는 가드는 제거되기 마련입니다.

mv를 파괴적인 작업에 포함시킨 것도 핵심입니다. 이동(move) 또한 원래 위치에서는 사라지기 때문입니다. rsync --delete와 find -delete도 잊기 쉬운 경로이므로 포함해 두었습니다.

auto 모드의 규칙을 직접 작성할 때의 주의사항입니다. 모르면 조용히 무방비 상태가 됩니다.

$defaults는 값이 아니라, **내장 규칙(built-in rules)을 해당 위치에 전개하는 마커(marker)**입니다.

"soft_deny": ["$defaults", "자신의 규칙 1", "자신의 규칙 2"]

여기서 중요한 것은, '배열을 쓰지 않는 것'과 '배열을 썼지만 $defaults가 없는 것'이 완전히 다른 동작을 한다는 점입니다.

4개의 섹션은 독립적으로 평가됩니다. environment만 작성하면 나머지 3개는 내장된 상태로 유지됩니다. 하지만 배열을 명시적으로 작성하고 $defaults를 누락하면, 해당 섹션의 내장 규칙은 모두 버려집니다.

특히 위험한 것이 soft_deny와 hard_deny입니다.

$defaults가 없는 soft_deny는 git push --force나 curl | bash에 대한 내장 차단 규칙을 모두 삭제합니다. hard_deny라면 내장된 데이터 유출 방지 및 auto 모드 우회 방지 규칙이 사라집니다.

직접 3줄을 작성했다고 생각했지만, 실제로는 '그 3줄 이외에는 전부 통과'되는 상태가 됩니다. 설정은 늘어난 것처럼 보이므로 겉모습만으로는 알아차릴 수 없습니다.

저장했다면 반드시 다음 명령어를 입력하십시오.

# $defaults 전개 후, 분류기(classifier)가 실제로 사용하는 실효 규칙을 JSON으로 표시
claude auto-mode config
# 내장 규칙만 표시
...

claude auto-mode config

전개(expand)된 후의 내용을 살펴보면, 내장 규칙이 사라졌는지 한눈에 알 수 있습니다. 설정을 작성할 때가 아니라, 전개된 후를 확인해야 합니다.

내장 규칙을 추가하는 것이 아니라 **재작성(rewrite)**하고 싶은 경우에는, claude auto-mode defaults의 출력을 파일에 저장한 뒤, 리스트를 편집하고 다시 붙여넣는 것이 정석적인 방법입니다.

한꺼번에 모두 넣지 않아도 괜찮습니다. 효과가 나타나는 순서대로 나열하면 다음과 같습니다.

1. 샌드박스(Sandbox) 관련 3줄. enabled / autoAllowBashIfSandboxed / failIfUnavailable . 이 설정만으로도 확인(confirmation)의 양과 안전성 모두가 달라집니다.

2. deny(거부)의 우회로 차단. wp eval 계열, 설정 파일 편집, curl, wget, nc. 개별적인 위험 작업보다 먼저 이곳을 막아야 합니다.

3. ask(질문) 최소화. 취소할 수 없는 작업만 남깁니다. 질문이 많아지면 읽지 않게 됩니다.

4. allow(허용) 범위 확대. 읽기, 탐색, 테스트할 항목들을 넣어 일상적인 작업이 중단되지 않는 상태로 만듭니다. 이 범위가 좁으면 결국 auto 모드의 의미가 퇴색됩니다.

5. $defaults 확인. claude auto-mode config를 한 번 실행합니다. 이미 auto 모드 규칙을 작성 중인 분들은 지금 바로 실행하세요.

6. 훅(Hook). permissions로 표현할 수 없는 것이 나타난 뒤에 작성해도 충분합니다. 저는 사고가 터진 후에야 작성했습니다.

--

• defaultMode: auto는 확인(confirmation) 이외의 상황에서 멈추는 메커니즘과 세트로 설정할 것
• autoAllowBashIfSandboxed와 failIfUnavailable은 반드시 둘 다 true로 설정
• deny는 "그 제한을 우회할 수 있는 범용적인 우회로"(wp eval / wp shell / 설정 파일 편집)부터 막을 것
• 읽기 권한(sed, awk, grep)과 데이터를 외부로 반출하는 경로(curl, wget, nc)를 분리할 것
• ask는 취소할 수 없는 작업만 남길 것. 범위를 좁힐수록 질문이 나왔을 때 읽게 됨
• git의 deny는 "되돌릴 수 없는 것"으로 한정할 것. commit / push를 막으면 일상적인 작업이 돌아가지 않음
• 인증 정보는 ~/.ssh뿐만 아니라, 본인의 배포 경로(SVN이라면 ~/.subversion/auth)도 막을 것
• 훅(Hook)은 fail-open 방식이어도 괜찮음. 외곽에 방어 계층이 있다면 내부에서는 너무 많이 멈추지 않는 것이 지속 가능함
• 가드(Guard) 패턴은 오작동(false positive)을 일으키지 않도록 할 것. prime-cache/는 막되 prime-cache.zip은 허용하는 식
• $defaults를 쓰는 것을 잊은 섹션은 내장 규칙이 모두 삭제됨. claude auto-mode config로 전개된 후를 반드시 확인할 것

한 달간 운용해 본 결과, 확인 작업이 격감했습니다. 그리고 확인 피로로 인한 실수도 줄었습니다. 확인 횟수를 늘리는 것보다, 확인이 발생했을 때 반드시 읽을 수 있는 상태를 만드는 것이 훨씬 효과적입니다. 도움이 되었다면 저장해 두었다가 설정을 구성할 때 다시 확인해 보세요.

평소에는 raplsworks.com에서 WordPress 플러그인 개발 및 Claude Code 관련 글을 쓰고 있습니다.