클로드 코드 권한 거부 규칙 — 앞 슬래시 함정·우회 5가지·감사 누락

권한 규칙은 한 번 적어 두면 그다음부터는 안 들여다보게 됩니다. 막아 뒀으니 막혔겠거니 하는 거죠.

그런데 최근 판올림 기록을 훑어보면 거부 규칙이 실제로는 안 걸리던 자리가 줄줄이 고쳐졌습니다. 여기에 판올림으로는 안 고쳐지는 내 설정 쪽 함정이 하나 더 있습니다.

📌 30초 요약

• 규칙에서 앞 슬래시 하나는 절대 경로가 아닙니다. 설정 파일 위치 기준입니다.
• 거부 규칙은 예외를 품을 수 없습니다. 좁은 허용이 있어도 넓은 거부가 이깁니다.
• 파일 쓰기·심볼릭 링크 등 다섯 자리에서 규칙이 안 걸렸습니다.
• 막힌 호출이 감사 출력에 안 남던 문제도 함께 고쳐졌습니다.

1. 거부가 언제나 이깁니다

규칙은 허용·확인·거부 세 갈래고, 우선순위는 거부가 맨 앞입니다. 넓게 친 거부 규칙은 더 좁은 허용 규칙과 같이 걸리는 호출까지 전부 막습니다. 그래서 문서가 한 줄로 못 박습니다 — 거부 규칙은 예외를 품을 수 없습니다.

확인 규칙도 똑같이 움직입니다. 더 구체적인 허용 규칙이 같이 맞아떨어져도 확인 규칙이 걸리면 물어봅니다. 「대부분 허용하고 몇 개만 빼겠다」는 구성을 규칙만으로 짜려다 막히는 이유가 여기 있습니다. 특정 값만 골라 막는 방법은 비싼 모델을 막는 한 줄에서 다룬 방식이 참고가 됩니다.

그럼 훅으로 우회할 수 있느냐. 안 됩니다. 훅이 「허용」을 돌려줘도 거부·확인 규칙은 그대로 평가됩니다. 방향이 반대일 때만 훅이 앞섭니다 — 종료 코드 2로 막는 훅은 권한 규칙을 보기도 전에 호출을 끊습니다. 그래서 「전부 허용해 두고 훅으로 몇 개만 막기」는 되고, 그 반대는 안 됩니다. 셸 없이 훅을 거는 방법과 묶어 두면 구성이 단순해집니다.

2. 앞 슬래시 하나가 만드는 함정

이건 판올림으로 안 고쳐지는, 처음부터 그렇게 설계된 규칙입니다. 경로 무늬에서 앞에 붙은 슬래시 하나는 파일시스템의 뿌리가 아니라 그 규칙을 적어 둔 설정 파일의 자리를 가리킵니다.

그러니까 같은 규칙을 어디에 적어 두느냐에 따라 전혀 다른 곳을 가리킵니다. 프로젝트 설정에 적으면 그 프로젝트 폴더 아래를, 개인 설정에 적으면 또 다른 곳을 봅니다. 진짜 절대 경로를 쓰려면 슬래시를 두 개 붙여야 합니다.

⚠️ 절대 경로인 줄 알고 쓴 규칙은 엉뚱한 곳을 막습니다

문서가 예로 드는 모양이 사용자 폴더 아래의 파일입니다. 그걸 슬래시 하나로 적으면 내 컴퓨터의 그 파일이 아니라, 설정 파일이 놓인 자리 아래의 같은 이름 경로를 가리킵니다. 그런 경로는 대개 존재하지 않으니 아무것도 안 막은 셈이 됩니다.

더 나쁜 건 오류가 나지 않는다는 점입니다. 규칙은 멀쩡히 등록되고, 경고도 없고, 겉보기에는 막아 둔 상태입니다. 민감한 경로를 규칙으로 막아 뒀다면 슬래시 개수부터 세어 보세요.

3. 안 걸리던 다섯 자리

여기부터는 프로그램 쪽 문제였고 최근 판올림에서 고쳐졌습니다. 문제는 이런 수정이 어디에도 따로 공지되지 않는다는 것입니다. 판올림 기록을 펼쳐 보지 않으면 내가 몇 달 동안 안 막힌 상태로 일했는지 알 길이 없습니다.

어디서	무슨 일이 있었나
셸로 파일 쓰기	화면과 파일에 동시에 쓰는 명령이 편집 거부 규칙과 쓰기 경로 검사를 비껴감
한 줄에 섞인 명령	검사기가 못 읽는 명령이 같은 줄에 있으면 읽기·편집 거부가 통째로 무시됨
심볼릭 링크 폴더	실제 위치로 적어 준 경로에 규칙이 안 걸리고, 반대 표기로 쓴 규칙도 셸에서 무시됨
느낌표로 시작한 규칙	자기 설정 파일 밖까지 번져 나감 · 이제 자기 출처 안에서만 적용
읽기만 하는 명령	세션이 오래 돌면 읽기 전용 이력 조회에도 허락을 묻기 시작함

첫 줄이 가장 아픕니다. 편집 도구는 막아 뒀는데 셸로 같은 파일을 쓰면 통과했다는 뜻이니까요. 이제는 그 명령이 쓰는 파일에도 편집 거부 규칙이 걸리고, 그 명령을 통째로 허용해 뒀더라도 작업 폴더 바깥 목적지는 더는 덮이지 않습니다.

넷째 줄은 방향이 반대라 헷갈리기 쉽습니다. 부정으로 시작하는 규칙이 너무 넓게 먹던 문제였습니다. 이제는 그 규칙을 적은 설정 파일 안에서만 효력이 있고, 아무것도 뒤에 붙지 않은 맨 느낌표는 무시됩니다. 규칙 자체를 취소한 셈이라 안 막히는 쪽으로 조용히 바뀝니다. 폴더 단위로 안 통하는 경우는 허용해 둬도 안 통하는 폴더 이야기에서 따로 다뤘습니다.

4. 막았는데 기록에 안 남던 것

규칙이 제대로 걸렸더라도 그 사실이 밖으로 안 나가면 조직 입장에서는 없었던 일이 됩니다. 자동화된 세션의 결과를 기계로 받아 보는 구성에서 경로 범위 거부 규칙에 막힌 읽기·편집·쓰기 호출이 거절 목록에서 빠지던 문제가 있었습니다.

새던 곳	무엇이 보였나
확장 꾸러미 오류	내려받는 주소에 들어 있던 토큰·비밀번호가 오류 문구에 그대로
서버 목록·상세	설정에 자리표시자로 적어 둔 비밀이 풀린 값으로 표시됨
풀어 놓은 꾸러미 파일	같은 컴퓨터의 다른 사용자가 읽을 수 있었고, 누구나 쓰기 가능한 상태로 남음

셋째 줄은 여러 사람이 한 서버에 들어와 쓰는 환경에서 의미가 큽니다. 풀어 놓은 파일이 남의 눈에 보였을 뿐 아니라 낡은 파일이 다시 풀어도 안 지워지고 남아 있었습니다. 셋 다 고쳐졌지만, 이미 그 상태로 돌던 기간이 있었다는 점은 달라지지 않습니다.

정리하면 이번 묶음의 교훈은 하나입니다 — 권한 규칙은 적어 둔 뒤 한 번은 시험해 봐야 합니다. 막으려던 동작을 일부러 시켜 보고 정말 막히는지 확인하는 것만으로 앞의 다섯 가지 중 상당수가 잡혔을 것입니다. 조직 차원에서 규칙을 잠그는 방법과 순서는 AI 도입 한 바퀴를 모아 둔 글에서 위치를 잡아 보세요.

자주 묻는 질문 (FAQ)

Q. 판올림만 하면 다 해결되나요?

다섯 자리 중 넷은 그렇습니다. 전부 프로그램 쪽 수정이라 새 판으로 올리면 끝입니다. 그런데 앞 슬래시 함정은 내 설정 문제라 판올림으로 안 고쳐집니다. 그리고 이미 그 상태로 돌던 기간에 무슨 일이 있었는지는 판올림이 되돌려 주지 않습니다. 민감한 경로가 걸려 있었다면 그 기간의 기록을 따로 보셔야 합니다.

Q. 거부 규칙에 예외를 두고 싶은데 방법이 없나요?

규칙만으로는 없습니다. 넓은 거부는 좁은 허용을 항상 이기고, 이건 설계된 동작입니다. 문서가 권하는 우회로는 방향을 뒤집는 것입니다 — 허용 목록에 넣어 두고, 막고 싶은 몇 개만 훅으로 거절하게 하는 구성이죠. 훅이 호출을 끊으면 허용 규칙을 보기 전에 멈추기 때문에 이쪽은 의도대로 동작합니다.

Q. 그럼 훅이 규칙보다 안전한가요?

한쪽 방향으로만 그렇습니다. 훅은 막는 쪽으로는 세지만 푸는 쪽으로는 힘이 없습니다. 훅이 「허용」을 돌려줘도 거부 규칙이 걸려 있으면 그대로 막힙니다. 관리자가 내려 둔 거부 규칙도 마찬가지고요. 훅은 규칙을 대신하는 장치가 아니라 규칙 앞에 하나 더 세우는 관문이라고 보는 편이 정확합니다.

Q. 회사 전체에 규칙을 강제하려면 어떻게 하나요?

관리자가 내리는 설정은 개인·프로젝트 설정이 덮어쓸 수 없습니다. 더 세게 잠그고 싶다면 권한 규칙의 출처를 관리 설정 하나로 제한하는 항목이 따로 있습니다. 이걸 켜면 개인 설정이나 프로젝트 설정에 적힌 규칙은 전부 무시됩니다. 다만 보안에 민감한 몇몇 항목은 예외로 빠져 있으니 목록을 한 번은 확인하세요.

정리하면

• 경로 규칙의 슬래시 개수부터 세어 보세요.
• 막으려던 동작을 일부러 시켜 보고 확인하세요.
• 예외가 필요하면 허용 + 훅으로 방향을 뒤집으세요.
• 판올림은 앞으로만 고칩니다. 지난 기간은 따로 보세요.

※ 공개된 판올림 기록과 권한 안내 문서를 읽고 정리했습니다. 설정 항목·명령·플래그는 우리말로 풀어 적었고, 각 우회 경로를 직접 재현해 보지는 않았습니다.

※ 어떤 판에서 언제부터 문제가 있었는지는 기록에 적혀 있지 않아 본문에서 뺐습니다. 영향을 받았는지 확인하려면 지금 쓰는 판 번호와 규칙을 적어 둔 시점을 함께 보셔야 합니다. 고쳐진 항목은 열람 시점의 최신 판 기준입니다.