이 글은 AI(Claude)가 검증과 초안을 작성했고, 필자가 내용을 확인한 것입니다. 아래에 적는 결과는 모두
필자의 환경(Windows 10, Claude Code 2.1.296)에서 실측한 것입니다. 다른 환경이나 버전에서도 같을 것이라고 단정할 수 없습니다.
이 글에서 알 수 있는 것
.claude/settings.json의 deny에 작업 폴더 외부를 지정했을 때, 필자의 환경에서는 시도한 쓰기 작업 중 어느 것도 막지 못했습니다. 시작 시 경고 메시지도 나오지 않았습니다 (../로 작성된 규칙 claude -p의 표준 에러 출력은 비어있음을 확인했습니다. (대화 모드는 미확인)). - 같은 장소를 절대 경로(//c/...)로 지정했을 때는, Write 툴, Edit 툴, Bash의 echo >는 막혔습니다. - 다만 절대 경로를 사용하더라도, Bash를 자동 허용하는 경우, node 스크립트에 의한 쓰기는 막히지 않았습니다. - 본인의 환경에서 더미 파일만을 사용하여 안전하게 확인하는 절차도 게재합니다.
무슨 일이 일어났는가
필자는 Claude Code를 두 개의 작업 폴더에서 사용하고 있었는데, 한쪽 폴더에서 다른 쪽 폴더를 덮어쓰게 하고 싶지 않았습니다.
work/
company/ ← Claude Code를 실행하는 장소
.claude/settings.json
...
그래서 company/.claude/settings.json에 다음과 같이 작성했습니다.
{ "permissions": { "deny": ["Edit(../shared/partner/**)"] } }
이것으로 보호하고 있다고 생각했습니다. 그런데 다른 목적으로 동작을 시도했을 때, 이 규칙이 있음에도 파일이 덮어쓰이는 것을 발견했습니다.
왜 작동하지 않는가 (공식 문서와의 관계)
공식 문서(Configure permissions)에 나와 있는 경로 작성 방식은 다음 4가지입니다.
| 작성 방식 | 의미 |
|---|
//path | 파일 시스템의 루트로부터의 절대 경로 |
~/path | 홈 폴더로부터 |
/path | 설정 위치에 따른 기준으로부터 (프로젝트 설정이라면 작업 폴더) |
path 또는 ./path | 현재 있는 폴더로부터 |
../로 시작하는 작성 방식은 이 표에 없습니다. 이번 결과는
기준을 잘못 파악하여 파일을 찾지 못한 것 같아, 올바른 위치를 다시 지정하자 덮어쓰기가 되었습니다(이 답변 자체는 기록에 남기지 않았습니다). Write 열은 이런 경우가 있기 때문에 6번 시도했습니다. - 'Bash (자동 허용 안 함)'가 멈추는 것은 deny 때문이 아니라, Bash를 허용하지 않기 때문입니다(deny가 없어도 멈춥니다). 이번에는 비대화형의 claude -p로 시도했기 때문에 즉시 거부되었습니다. 대화 모드에서는 실행 전에 확인 메시지가 나와야 합니다(미검증). - Write(...)라는 규칙도 시도해봤지만, 시작 시에 'Write(path)는 파일 권한 체크에 사용되지 않습니다. Edit(path)를 사용하는 것이 좋습니다'라는 취지의 경고가 나왔습니다. 쓰기 금지는 Edit(...)로 작성합니다.
자신의 환경에서 안전하게 확인하는 절차
실제 파일에서는 시도하지 마십시오. 아래의 절차는 홈 폴더에 매번 새로운 테스트용 폴더를 만들고, 그 안의 더미 파일만 사용합니다.
- Git Bash를 열고 다음 내용을
try-deny.sh라는 이름으로 저장합니다.
#!/usr/bin/env bash
# deny 규칙이 '인접 폴더로의 쓰기'를 막는지, 더미 파일만으로 테스트 (Git Bash용).
set -eu
...
bash try-deny.sh relative
작성자 환경에서는 '더미 파일이 변경되었습니다'라고 나왔습니다. '판단할 수 없습니다'가 나왔을 때는 AI가 쓰기를 시도하지 않았다는 뜻이니, 다시 실행해 주십시오.
bash try-deny.sh absolute
작성자 환경에서는 '더미 파일은 변경되지 않았습니다'라고 나왔습니다.
-
끝나면 표시된 테스트용 폴더(cc-deny-test-...)를 삭제합니다.
-
--permission-mode acceptEdits는 '편집을 확인 없이 통과시키는' 모드입니다. 평소에 편집을 자동으로 허용하는 사람의 상태를 재현하기 위해 사용했습니다. - Claude 이용료가 몇 원 정도 들었습니다(작성자 환경에서는 1회당 약 0.003달러. 스크립트에서는 --model haiku를 지정했습니다).
어떻게 해야 하는가 (작성자의 대책)
- 작업 폴더 외부를 보호하는 규칙은 절대 경로(
//c/...)나 ~/로 작성합니다. 작성자는 절대 경로로 확인했습니다(~/ 형태는 미검증입니다). - 쓰기 금지는 Edit(...)로 작성합니다. - Bash를 자동으로 허용하지 않습니다. 절대 경로 규칙에서도 Bash로 다른 프로그램을 실행하면 쓸 수 있었습니다. 명령어는 실행할 때마다 내용을 보고 허용해야 합니다. - 규칙을 작성했다면, 실제로 막히는지 테스트합니다. 위의 try-deny.sh는 '쓰는 방법'을 테스트하는 것입니다. 자신의 settings.json 자체를 테스트하려면, 템플릿의 README에 있는 확인 절차(당신의 settings.json 복사본으로 시도)를 사용하십시오. 설정 파일에 작성한 것이 보호되고 있다는 증거가 되지 않습니다. 또한, 어느 쪽 절차로 막혔다고 나와도 알 수 있는 것은 'Write 도구가 막혔다'는 것뿐입니다. Bash 경유 스크립트 등 다른 경로까지 보호된다는 보장은 아닙니다.
deny는 '브레이크'이지, 벽이 아니다
- deny는 Claude Code가 자신의 도구(Read・Write・Edit・Bash 등)를 사용할 때 작동하는 브레이크입니다. 이번처럼 쓰는 방법이나 경로에 따라서는 효과가 없습니다. - 다른 검증에서는 작업 폴더 안의
.env 파일을 Read(./.env)로 금지했습니다. Read 도구와 cat .env는 멈췄지만, Bash를 자동으로 허용하고 있으면, (Bash를 자동으로 허용하지 않으면 멈췄습니다). node -e로 .env를 읽는 스크립트는 실행할 수 있었습니다 - 이는 공식 문서에도 쓰여 있는 사양입니다. Configure permissions에는 Read・Edit의 deny가 Claude의 내장 도구나, Bash의 cat・sed・tee
・리다이렉트 등에는 효과가 있지만, 'Python이나 Node의 스크립트가 스스로 여는 파일'에는 효과가 없다. OS 레벨에서 막으려면 샌드박스를 활성화해야 한다는 취지의 설명이 있습니다 (2026년 10월 11일 확인). - 정말로 읽게 하거나 쓰게 하고 싶지 않은 것은 Claude Code 설정에만 의존하지 말고, 다음과 같은 OS나 실행 환경의 메커니즘도 고려해 주세요. - 다른 Windows 사용자 계정으로 Claude Code를 구동하고, 해당 사용자에게 파일 권한을 부여하지 않기 - 가상 머신(VM)이나 컨테이너 등 격리된 환경에서 구동하기 - 실제 운영 키(key) 같은 것은 애초에 같은 PC에 두지 않기
- '작업 폴더 외부에 두면 안전하다'는 것도 아닙니다. 이번 결과와 같이, 외부 폴더도 작성 방식에 따라 접근할 수 있습니다.
검증한 환경과 확인하지 않은 것
실측한 환경
- Windows 10 (10.0.19045), Git Bash, Node.js v24, Claude Code 2.1.296 (2026년 10월)
- 설정은 프로젝트의
.claude/settings.json만 사용했습니다. additionalDirectories는 사용하지 않았습니다 - 실행은 비대화형(claude -p)으로 했고, 모델은 haiku를 사용했습니다
확인하지 않은 것
- 대화 모드에서의 동작, Mac・Linux, 다른 버전, haiku 외의 모델
cp・mv・python・PowerShell 등 다른 쓰기 경로 - ~/path・/path 형태의 작성 방식 - Claude Code의 샌드박스 기능
관련 보고로, Claude Code 공식 리포지토리에는 --add-dir 등으로 추가한 작업 폴더에 상대 경로의 deny가 효과가 없다는 issue가 있습니다 (anthropics/claude-code #89470). 조건은 이번과 같지는 않습니다.
논의(Discussion)
