
배포 중인 안전 후크가 '확인해야 할' 조작을 묵묵히 통과시키고 있지는 않은가 —— 나의 910개를 다시 세어보았다
요약
Claude Code의 안전 후크(`cc-safe-setup`)가 `bypassPermissions` 모드에서 '확인 요청(ask)'을 무시하고 자동으로 승인하는 보안 취약점을 분석하고 수정했습니다. 작성자는 910개의 후크를 전수 조사하여 잘못된 주석과 동작 로직을 바로잡았습니다.
핵심 포인트
- bypassPermissions 모드에서는 'ask' 판정이 자동으로 승인됨
- 보안 후크가 사용자에게 확인을 요청하는 것처럼 보이지만 실제로는 통과될 수 있음
- 강력한 차단을 위해서는 'ask' 대신 'deny' 또는 'exit 2'를 사용해야 함
- 배포 중인 910개 후크에 대한 전수 조사 및 주석 수정 완료
나는 Claude Code의 안전 후크를 무료로 배포하고 있다(cc-safe-setup). 위험한 조작을 실행하기 직전에 멈추기 위한 작은 후크들의 모음이다. 그렇기에 이런 보고가 나왔을 때는 남의 일이 아니라, 내가 배포한 물건을 확인할 차례라고 받아들인다.
보고 내용은 이렇다. PreToolUse 후크가 '사람에게 확인시키기' 판정(permissionDecision: "ask")을 반환하더라도, 세션이 bypassPermissions(권한 확인을 건너뛰는 모드)로 동작하고 있으면, 그 확인은 묵묵히 자동으로 승인되어 툴이 그대로 실행된다. 반면 '거부' 판정(deny)은 같은 상황에서도 제대로 작동한다.
이는 위험한 조작에 대해서만 사람의 확인을 거치고 싶다는 안전 후크의 가장 중요한 사용법을 조용히 무효화한다. 화면에는 아무것도 나타나지 않는다. 사용하는 쪽은 '확인을 거쳤다'고 생각하고 있지만, 실제로는 그냥 통과되고 있는 것이다.
그래서 나는 내가 배포하고 있는 910개의 후크를 내 환경에서 다시 세어보며, 어떤 것이 살아남고 어떤 것이 묵묵히 통과시키는 쪽인지 분류했다. 그리고 세는 도중에 내 코드에서 발견한 잘못된 주석을 수정했다. 아래는 그 기록이다. 보고 자체는 전언(傳聞), 세어본 결과와 수정한 부분은 직접 측정한 실측치로 나누어 작성한다.
출처는 GitHub의 이슈 #77212(2026-07-13・OPEN)이다. 보고자는 permissions.defaultMode를 bypassPermissions로 설정한 상태에서, ask를 반환하는 후크와 deny를 반환하는 형제 후크를 동일한 세션에서 실행하여 다음을 관측했다.
ask를 반환한 쪽의 대상은 확인 다이얼로그가 전혀 나타나지 않고 그대로 실행되었다.deny를 반환한 쪽의 대상은 동일한 세션에서 올바르게 차단되었다.- 후크 자체는 동작하고 있으며,
askJSON을 출력하고 있다는 것도 (동일한 입력을 수동으로 후크에 흘려보내) 확인했다.
즉, 후크가
를 반환한다.
여기서 내 코드의 주석에 거짓이 있었다. ask를 반환하는 부분에 이렇게 적혀 있었다—— "대화 모드가 아닐 때는 이것이 쓰기를 중단한다 (Claude Code는 미승인으로 처리한다)". 이는 bypassPermissions 하에서는 잘못된 내용이다. 이슈에 보고된 대로, 해당 모드에서는 ask가 묵묵히 승인되므로 중단되지 않는다. 과거의 내가 확인도 하지 않고 "중단될 것이다"라고 적어두었던 것이다. 이번에 그 파일을 직접 확인하고 나서야 처음으로 깨달았다.
두 번째는 mcp-tool-guard.sh이다. MCP의 툴이 이름만으로는 알 수 없는 파괴적인 조작(예를 들어 자동 조작으로 '삭제' 버튼을 눌러 운영 데이터를 지우는 것)을 자동 승인 모드 하에서 에스컬레이션하는 후크다. 파괴적인 툴 이름(delete / remove / drop 등)이나 운영 호스트에 대한 조작은 exit 2와 deny로 강력하게 차단한다. 하지만 임의 설정(CC_MCP_AUTOMATION_GUARD=ask)으로 했을 때의 "자동 조작 확인" 분기가 ask를 반환한다. 하필이면 이 분기가 발화하는 조건은 모드가 bypassPermissions 등의 자동 승인일 때——즉 ask가 묵묵히 통과되는 바로 그 상황이었다. 나 자신을 속이는 형태가 되어 있었다.
찾았기에 수정했다. 동작 그 자체(ask 선택지)는 없애지 않는다. 대화 세션에서는 ask가 올바르게 확인을 요청하며, 그것을 요구하는 사용법은 타당하기 때문이다. 내가 수정한 것은 "오해를 불러일으키는 기술"이다.
memory-write-guard.sh: 거짓된 주석을 정확한 기술로 바로잡았다. bypassPermissions 하에서는 ask가 묵묵히 승인되어 쓰기가 중단되지 않으며, 강제하고 싶다면 CC_MEMORY_WRITE_APPROVAL=block (exit 2)를 사용해야 한다. 이는 항상 존중된다고 명시했다.
mcp-tool-guard.sh: ask 분기 직전에 동일한 주의 사항을 추가했다. bypassPermissions는 ask를 묵묵히 자동 승인하므로, 자동 승인 모드에서 강력하게 강제하고 싶다면 CC_MCP_AUTOMATION_GUARD=block (exit 2)를 사용하라고.
둘 다 block (exit 2) 선택지는 처음부터 있었으며, 그쪽은 살아남는다. 따라서 사용자가 bypassPermissions로 실행한다면 block을 선택하면 된다는 것을 알 수 있는 형태로 만들었다.
여기까지가 7월 16일의 이야기다. 이 기사를 공개하기 전(7월 26일)에 만일을 위해 다시 한번 세어보았다. 그러자 두 가지 상황이 변해 있었다.
첫 번째. memory-write-guard.sh에 넣었어야 할 정확한 기술이 사라져 있었다. 수정 후, 이 후크는 다른 개편 과정에서 다시 작성되었고, 그 재작성이 오래된 주석——"대화 모드가 아닐 때는 ask가 쓰기를 중단한다"라는, 바로 내가 거짓이라고 확인하고 지웠던 기술——을 부활시켜 놓았다. 고쳤던 거짓말이 10일 만에 되돌아와 있었다.
두 번째. ask를 사용하는 후크가 2개에서 3개로 늘어나 있었다. 늘어난 1개는 PowerShell의 삭제 가드로, Remove-Item -Recurse -Force의 절대 경로 실행에 확인을 거치는 분기가 ask를 반환한다. 하필이면 이 확인이 정말로 필요한 상황의 대부분——무인 자동 운용——은 bypassPermissions로 돌아가고 있으며, 거기서는 확인이 묵묵히 승인된다.
그래서 둘 다 그 자리에서 바로잡았다(현재 실체는 총 908개, 강력한 거부 284개, ask 3개이며, 3개 모두 bypassPermissions에서는 확인이 나오지 않는다는 주의 사항을 적어 넣었다). 이 재점검을 통해 알 수 있는 것은, 한 번 고친 것도 계속해서 확인하지 않는 한 올바른 상태로 남아있지 않다는 것이다. 수정 사항은 개편의 파도에 휩쓸린다. 후크의 안전은 재고(inventory)에 있는 것이 아니라, 다시 세어보는 습관에 있다.
요약하자면 다음과 같다.
bypassPermissions (또는 --dangerously-skip-permissions)로 실행한다면, 후크의 "확인(ask)"는 믿을 수 없다. 묵묵히 통과된다. 효과가 있는 것은 강력한 거부(exit 2 또는 deny)뿐이다. 그러므로 절대로 자동으로 실행시키고 싶지 않은 조작은 ask가 아닌 exit 2로 중단시키는 설계로 만들어야 한다. 사람의 예외가 필요하다면, 그 자리에서의 확인이 아니라 설정이나 환경 변수와 같은 별도의 경로를 통해 명시적인 허가를 내어주어야 한다.
그리고——내가 배포하는 것들이나 나의 설정을, 보고가 올라오면 실제로 다시 세어본다. "멈춰야 한다"라고 적어둔 주석은, 확인하기 전까지는 반드시 옳다고 할 수 없다. 나 자신도 직접 확인하고 나서야, 2개의 구멍과 1개의 거짓 주석을 발견했다.
당신의 후크(hook)에서도 똑같은 일을 할 수 있다. 후크 디렉토리에서 강제하는 방식을 세어보는 것이 좋다.
# 엄격한 거부(bypass에서도 작동함)를 사용하는 후크
grep -rl 'exit 2' ~/.claude/hooks/ .claude/hooks/ 2>/dev/null
# ask를 반환하는 후크(bypassPermissions에서는 묵묵히 통과됨 = 과신 금지)
...
ask를 반환하는 후크가 있고, 동시에 bypassPermissions로 실행하고 있다면, 그 후크는 지금 확인 요청을 내보내지 않고 있다. 강제하고 싶다면, 그 후크를 exit 2 거부로 바꾸거나, bypass 모드를 중단하고 기본 모드로 되돌려야 한다.
내가 배포하는 안전 후크 모음인 cc-safe-setup은, 이 글에서 세어본 바와 같이 파괴적인 조작을 엄격한 거부(exit 2)로 차단하도록 설계되었다. 도입은 다음 한 줄로 가능하며, MIT 라이선스의 무료 소프트웨어이다.
npx cc-safe-setup
그리고, 이러한 "멈춰 있다고 생각했지만, 사실은 묵묵히 통과되고 있었다"라는 침묵의 실패를 포함하여, Claude Code에서 실제로 발생한 사고를 「증상 → 탐지 → 복구 → 예방」 순으로 정리한 단권 도서(Anthropic 공식 가이드에는 없는 사고 방지법 · ¥800)도 출간했다. 무단 종량제 과금, 부수 작업자의 폭주, 설정이 묵묵히 원래대로 돌아가는 사고 등, 표시와 실태가 어긋나 돈이나 데이터가 조용히 녹아내리는 유형을 여러 장에 걸쳐 다루고 있다. 제3장까지 무료로 미리 읽을 수 있으며, 이후에도 매달 새로운 사고를 추가하여 구매자에게는 무상 업데이트로 제공된다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기