설정했는데 왜 그럴까요? Claude Code의 권한이 작동하지 않는 이유와 지금 당장 할 수 있는 대책

Claude Code를 사용하기 시작하고 얼마 지나지 않아, 거의 모든 사람이 부딪히는 벽이 있습니다.

settings.json에 권한을 설정했는데도 매번 이 메시지가 나옵니다.

Allow this bash command?
ls -d /Users/xxx/Project/*/
1 Yes
...

설정했잖아요.

Bash(ls *)도 적었습니다. Bash(git status)도 적었는데, 매번 물어봅니다.

'쓰는 방식이 틀린 건가?'라며 표기법을 바꿔보고 또 바꿔봐도 결과는 같습니다.

실제로는 이것이 설정 작성 방식의 문제가 아니라, Claude Code 자체의 버그입니다.

GitHub에는 같은 고민의 Issue가 30건 이상 쌓여있으며, 전 세계의 Claude Code

전 세계 개발자들이 시행착오를 거치면서 영어권 커뮤니티에서는 다음과 같은 인식이 정착되었습니다.

"Permissions는 요청, Hooks는 강제 실행"

Claude Code에는 PreToolUse Hooks라는 메커니즘이 있습니다. 명령어가 실행되기 직전에 개입하여 "이 명령어는 허용한다 / 하지 않는다"를 프로그램으로 판별할 수 있습니다.

버그가 있는 패턴 매칭을 사용하는 대신, 직접 명령어를 파이프 분할하여 개별적으로 판별하면 문제가 해결됩니다.

게다가 공식 문서에도 이 사용법이 추가되었습니다.

"모든 Bash 명령어를 프롬프트 없이 실행하고 싶다면 Bash를 allow 목록에 넣고, 차단하고 싶은 특정 명령어는 PreToolUse Hook으로 거부하세요"

즉, '퍼미션 = 편의성 확보용', 'Hooks = 안전 확보용'이라는 사용 구분이 정답이라는 인식에 공식 측도 동참하고 있습니다.

GitHub Issue #18846에서 시작된 Python 버전입니다.

따옴표 처리 지원, 리다이렉트 제거, deny 규칙 대응까지 포함되어 있어 동작도 안정적입니다.

~/.claude/hooks/smart_approve.py 파일을 생성하고 실행 권한을 부여합니다.

#!/usr/bin/env python3
import json, sys, re
from pathlib import Path
...

chmod +x ~/.claude/hooks/smart_approve.py

~/.claude/settings.json에 Hooks를 등록합니다.

{
"permissions": {
"allow": [
...

command의 경로는 환경에 따라 틸드(~) 확장이 제대로 작동하지 않는 경우가 있습니다. /Users/yourname/처럼 전체 경로(full path)로 작성하는 것이 확실합니다.

Claude Code를 재시작하면 완료됩니다.

해외 엔지니어가 공개한 OSS인 kornysietsma/claude-code-permissions-hook도 있습니다. TOML 파일로 allow/deny 규칙을 정규 표현식으로 정의할 수 있으며, 감사 로그(audit log) 기능까지 기본 탑재되어 있습니다.

여러 사람이 Claude Code를 사용하는 팀이거나, "누가 언제 어떤 명령어를 실행했는지"를 기록하고 싶은 경우 특히 유용합니다.

[audit]
audit_file = "/tmp/claude-tool-use.json"
audit_level = "matched" # off / matched / all 중에서 선택
...

Python 버전과 비교했을 때 도입 비용은 더 높지만, 보안성과 가시성은 차원이 다릅니다.

상황	추천
개인 이용, 간편하게 시작하고 싶을 때	① Python 버전
팀 이용, 감사 로그가 필요할 때	② Rust 기반 라이브러리

'원클릭으로 설치 가능한 툴'을 소개하는 글도 보이지만, 출처 불명의 npx xxx는 주의해야 합니다.

실행하는 것은 위험합니다. 2026년 4월, Claude Code의 npm 에코시스템을 노린 공급망 공격이 실제로 발생했으며, 트로이 목마가 포함된 패키지가 유통되었습니다. Hook 계열 도구는 커맨드 실행 전에 개입하는 구조상, 악성 코드가 혼입되어 있다면 피해가 커집니다. 공식 리포지토리나 내용물을 직접 읽을 수 있는 스크립트만 사용해 주세요.

'좋아, 해결!'이라고 생각했을 때 또 다른 함정이 있습니다(웃음)

ls -la /path/ | grep -E "Knowledge|Skill"

grep -E "Knowledge|Skill"

안의 |

을 스크립트가 파이프로 오인하여 분리해 버리는 경우가 있습니다.

인터넷에 떠도는 간단한 Hook 스크립트를 그대로 사용하면 안 됩니다. 위에 제시된 Python 버전과 Rust 버전은 둘 다 따옴표 처리가 되어 있어 문제없습니다.

해외 Issue(#27803, #36900)에서 보고되었던 케이스입니다.

# Bash(git status)를 설정해도 통하지 않음
git -C /path/to/repo status

git

커맨드를 허용했더라도, -C

플래그와 함께 실행되면 패턴에 매치되지 않습니다.

대책은 Hook의 판별 로직을 정규 표현식 기반으로 확장하는 것(② Rust 버전이 유리)입니다.

해외 Issue(#37210)에서 보고된 내용입니다.

Hook에서 permissionDecision: "deny"를 반환해도, Edit/Write는 파일이 변경되는 경우가 있습니다.

궁금한 분은 파일을 chmod 444로 읽기 전용으로 만드는 이중 방어를 고려해 주셨으면 합니다.

settings.json의 퍼미션 설정이 작동하지 않는 것은 버그입니다. GitHub에 30건 이상의 Issue가 있으며, 전 세계 개발자들이 같은 문제를 겪고 있습니다 - 버그의 정체는 '파이프로 연결된 복합 커맨드가 패턴 매치되지 않음' 때문입니다.

• 해결책은
  PreToolUse Hooks에서 퍼미션 판별을 직접 구현하는 것입니다 - 개인 이용이라면 Python 버전, 팀 이용이라면 Rust 라이브러리가 추천됩니다.
• Hook에도 따옴표 내부의 파이프(pipe), -C 플래그, Edit/Write 함정이 있으니 주의하세요 - 출처 불명의
  npx

도구는 사용하지 마세요.

공식에서 수정해 주는 것이 가장 좋지만, 그때까지 현실적인 대책으로 참고해 주시면 좋겠습니다.

버그가 고쳐지면 Hooks를 제거하기만 하면 되므로, 도입 비용은 그렇게 높지 않습니다.

Claude Code, 정말 편리합니다. 그렇기 때문에 퍼미션 관련 버그가 더욱 눈에 띕니다(웃음)

'설정했는데 물어본다'는 스트레스를 없애고 더 쾌적하게 사용할 수 있게 되면 좋겠습니다.

또한, '이런 과제가 있는데 해결할 수 있을까'와 같은 것이 있으시면 꼭 연락 주세요. 가능한 한 대응해 보고 싶습니다(대응한 경우에는 기사에 게시하겠습니다. 이 점은 양해 부탁드립니다).

X는 여기입니다.