클로드 코드 보안: 다시 묻지 않기 누르자 비밀번호가 파일에 남았다

핵심 요약

• Claude Code 승인 창에서 "Yes, and don't ask again"(다시 묻지 않기)을 고르면, 그 명령이나 명령의 앞부분이 .claude/settings.local.json의 허용 규칙으로 저장됩니다. 저장되는 부분에 비밀번호가 들어 있으면 비밀번호도 함께 저장됩니다. 필자가 Claude Code 2.1.319에서 가짜 비밀번호로 해 보니 PGPASSWORD=...로 시작하는 명령은 비밀번호가 평문 그대로 규칙에 남았습니다.
• 보안 업체 Apiiro는 공개 GitHub에서 이 파일 104,185개를 모아, 1,122개(1.1%)에서 비밀값을 찾았습니다. 이 파일들에 든 서로 다른 비밀은 1,379개이고 그중 379개가 데이터베이스 비밀번호입니다. Apiiro는 어떤 자격 증명도 실제로 써 보지 않았으므로 "유효한 키 1,379개"라는 뜻은 아닙니다.
• Claude Code는 이 파일을 처음 만들 때 저장소의 .gitignore가 아니라 개발자 컴퓨터의 전역 git 제외 목록에만 등록합니다. 그래서 같은 프로젝트를 전역 설정이 없는 다른 컴퓨터, 컨테이너, 복사한 폴더에서 다루거나 파일이 이미 커밋돼 있으면 막아 주지 못합니다. 필자 맥의 저장소 121개를 점검해 보니 업무 저장소 3곳은 이 파일이 이미 커밋돼 있었습니다(비밀값 패턴은 없었습니다).
• gitleaks와 TruffleHog도 비밀이 든 파일 1,122개 중 215개는 둘 다 잡지 못했습니다. 명령 속에 섞인 일반 비밀번호는 키 형식이 없어서입니다.
• 점검은 세 가지면 됩니다. 파일이 git에 추적되는지, 이력에 남은 적이 있는지, 허용 규칙에 비밀번호가 들어 있는지 봅니다. 나왔다면 비밀번호부터 바꾸고, 저장소 .gitignore에 파일을 넣고 추적을 끊습니다.

목차

• 클로드 코드 보안 문제, 무엇이 저장되나
• 직접 눌러 보니: 2.1.319에서 남은 것
• 전역 gitignore만으로는 왜 못 막나
• 1,122개라는 숫자 읽는 법
• 스캐너도 다섯 개 중 하나를 놓쳤다
• Anthropic의 답변과 auto mode
• 내 저장소 점검하는 법
• 다시 생기지 않게 하는 권한 설정
• 출처

클로드 코드 보안 문제, 무엇이 저장되나

이번 클로드 코드 보안 문제는 승인 창의 "다시 묻지 않기"가 명령 문자열(또는 그 앞부분)을 그대로 프로젝트 폴더의 .claude/settings.local.json에 허용 규칙으로 적고, 그 파일이 코드와 함께 공개 저장소에 올라간 일입니다. Anthropic 공식 문서도 이 동작을 적어 두었습니다. 문서는 Bash 명령 승인 창에서 "Yes, and don't ask again"을 고르면 Claude Code가 그 승인을 이 파일에 allow 규칙으로 저장한다고 설명합니다(Claude Code 설정 문서). 권한 문서는 이 선택의 효과를 "저장소와 명령 단위로 영구"라고 적었습니다(Claude Code 권한 문서).

문제는 규칙의 내용입니다. Apiiro는 2026년 11월 5일 낸 연구 글에서 "규칙은 명령 문자열 그 자체"라고 썼습니다(Apiiro). 데이터베이스를 확인해 달라고 하면 Claude Code가 제안하는 명령에는 접속 비밀번호가 들어갑니다. 비밀번호 없이는 명령이 돌지 않기 때문입니다. 그 명령을 "다시 묻지 않기"로 승인하는 순간 비밀번호가 파일에 남습니다. Apiiro는 이 동작이 모델이 아니라 Claude Code 자체의 동작이며 Opus 5.5와 Fable 5.1로도 재현했다고 밝혔습니다.

이 파일은 원래 내 컴퓨터에만 두는 파일입니다. 설정 문서는 프로젝트 로컬 설정을 "이 프로젝트에서 나에게만" 적용되는 범위로 소개합니다. 그런데 파일 위치가 프로젝트 폴더 안이라, 무시 규칙이 빠지면 git add . 한 번에 다른 코드와 함께 커밋됩니다. Claude Code를 어떻게 설정하는지는 Claude Code 팁 11가지에서 설정 파일의 범위와 함께 정리했습니다.

직접 눌러 보니: 2.1.319에서 남은 것

필자는 2026년 11월 9일 맥에서 Claude Code 2.1.319를 권한 모드 default, 모델 Haiku 5.5로 띄우고, 빈 git 저장소에서 가짜 비밀값이 든 명령 네 개를 차례로 요청했습니다. 실제 전역 git 설정을 건드리지 않도록 GIT_CONFIG_GLOBAL로 임시 전역 설정을 따로 지정했습니다. 승인 창의 2번 선택지("Yes, and don't ask again for:")에 뜬 문구는 이렇습니다.

첫째와 셋째 명령에서 2번을 골랐고, 파일에는 다음 두 줄이 저장됐습니다.

{
  "permissions": {
    "allow": [
      "Bash(PGPASSWORD=demo-NOT-a-real-pw-5678 printenv PGPASSWORD *)",
      "Bash(curl *)"
    ]
  }
}

두 가지가 보입니다. 첫째, 2.1.319는 curl, psql처럼 흔한 명령이면 "명령 이름 + *" 꼴의 접두어 규칙을 제안해서 인자 속 토큰이나 접속 문자열은 남지 않았습니다. 대신 curl *는 앞으로 모든 curl 명령을 묻지 않고 실행하라는 넓은 허락이 됩니다. 둘째, 명령이 PGPASSWORD=...처럼 환경 변수 대입으로 시작하면 그 대입까지 접두어에 들어가 비밀번호가 평문으로 남았습니다. Apiiro 그림의 승인 창도 똑같이 PGPASSWORD=... psql *를 제안합니다. Apiiro가 스캐너가 놓친 사례로 꼽은 것도 PGPASSWORD=, sshpass -p, mysql -p 뒤에 붙은 비밀번호였습니다.

이 실험은 2.1.319 한 버전에서 명령 네 개로 본 결과입니다. Apiiro가 모은 공개 파일들이 어느 버전에서 만들어졌는지는 알 수 없고, Apiiro가 예로 든 규칙에는 Bash(psql postgres://admin:****@db...)처럼 접속 문자열이 통째로 든 것도 있습니다. 비슷한 명령(DB_PASSWORD=가짜값 printenv DB_PASSWORD)을 auto mode에서 요청하니 승인 창 없이 바로 실행됐고, .claude 폴더도 만들어지지 않았습니다.

전역 gitignore만으로는 왜 못 막나

Claude Code는 이 파일을 처음 쓸 때 개발자 컴퓨터의 전역 git 제외 목록에 **/.claude/settings.local.json 한 줄을 넣습니다. 공식 문서의 설명은 이렇습니다. 파일을 무시하지 않는 저장소에서 처음 쓸 때 전역 제외 파일에 이 패턴을 넣고, 전역 제외 파일은 core.excludesFile가 절대 경로나 ~로 시작하는 경로로 지정돼 있으면 그 파일, 아니면 $XDG_CONFIG_HOME/git/ignore나 ~/.config/git/ignore라고 적었습니다(Claude Code 설정 문서). 필자 실험에서도 처음 규칙을 저장하자 비어 있던 임시 전역 제외 파일에 이 한 줄이 생겼고, 저장소의 .gitignore는 만들어지지 않았습니다.

이 방식은 내 컴퓨터에서만 통합니다. git 공식 문서는 clone으로 다른 저장소에 함께 배포돼야 하는 패턴은 .gitignore에, 사용자가 어디서든 무시하고 싶은 패턴은 사용자 ~/.gitconfig의 core.excludesFile에 두라고 구분합니다(git gitignore 문서). 전역 제외 목록은 내 컴퓨터의 설정이라 저장소와 함께 다니지 않습니다. 같은 문서는 "이미 git이 추적하는 파일은 영향을 받지 않는다"고도 적었습니다.

필자는 같은 실험 저장소를 전역 설정이 없는 컴퓨터처럼 열어 봤습니다(GIT_CONFIG_GLOBAL=/dev/null, 빈 XDG_CONFIG_HOME). git status에 ?? .claude/settings.local.json이 떴고, git add -A를 미리 돌려 보니 이 파일이 추가 대상에 들어갔습니다. 저장소 .gitignore에 .claude/settings.local.json 한 줄을 넣자 같은 조건에서도 무시됐습니다.

Apiiro가 꼽은 빈틈도 같습니다. 나중에 git 저장소가 된 폴더, 다른 컴퓨터의 클론, 누군가 이미 커밋한 파일은 전역 목록이 막지 못하고, 규칙이 저장소 .gitignore로는 들어가지 않는다는 것입니다(Apiiro). Apiiro 연구진은 해커 뉴스에서 처음에 "새로 클론하면" 커밋된다고 썼다가, 새로 클론한 저장소에는 파일이 없다는 지적을 받고 "새 컴퓨터나 전역 제외가 없는 컨테이너, 복사한 프로젝트 폴더, 이미 커밋된 파일"로 고쳤습니다(해커 뉴스).

이미 커밋된 파일이 가장 조용한 경우입니다. Apiiro에 따르면 Claude Code는 파일이 추적 중이라는 사실을 디버그 로그에만 남기고 사용자에게는 알리지 않으며, 다음 승인도 그 추적 중인 파일에 덧붙입니다. 필자 맥의 ~/Desktop/develop 아래 깊이 3까지의 git 저장소 121개를 훑어보니 31곳에 이 파일이 있었고, 그중 24곳(업무 저장소 3개와 그 클론, 워크트리)에서 파일이 git에 커밋돼 있었습니다. 세 저장소 모두 2025년 11~12월에 처음 커밋됐습니다. 다행히 지금 파일과 그 이력 어디에도 비밀번호 패턴은 없었지만, 앞으로 누르는 "다시 묻지 않기"는 그대로 커밋될 상태였습니다.

사건 전에 나온 국내 설정 안내 중에는 이 한계를 다루지 않은 곳이 있습니다. 한 Claude Code 설정 가이드는 전역 제외 파일에 등록해 주기 때문에 "실수로 커밋될 걱정도 없어요"라고 설명합니다(달레 코딩). 내 컴퓨터 하나만 놓고 보면 맞는 말이지만, 팀 저장소와 다른 컴퓨터까지 놓고 보면 위의 빈틈이 남습니다.

1,122개라는 숫자 읽는 법

1,122는 비밀이 든 "파일" 수이고, 1,379는 그 파일들에 든 서로 다른 "비밀" 수입니다. 보도마다 숫자가 섞여 있어 Apiiro 원문으로 정리했습니다(Apiiro).

• 표본: 2026년 11월 1~3일 GitHub 코드 검색으로 찾은 공개 .claude/settings.local.json 104,185개(저장소 103,617개). 기본 브랜치만 봤고 전부 내려받았습니다.
• 비밀이 든 파일: 1,122개(1.1%). 안에 든 고유 비밀은 1,379개로, 제공사 키 636개와 공개 호스트용 비밀번호·토큰 743개입니다.
• 종류: 데이터베이스 비밀번호 379개, Supabase 서비스 역할 키 122개, Supabase 계정 토큰 103개, SSH 로그인 43개, GitHub·GitLab·npm 토큰 42개, AWS 키 23개, 개인 키 6개.
• 범위를 넓힌 합계: 파일의 과거 버전, 팀이 일부러 커밋하는 공유 .claude/settings.json, 저장소에 남은 에이전트 대화 기록까지 더하면 1,994개 저장소에서 2,539개입니다. 지금 사본에는 없고 과거 버전에만 남은 비밀(대개 파일을 지운 경우)도 509개 저장소에서 734개였습니다.
• 조직: 비밀 대부분은 개인 개발자의 것이었고, 비밀이 공개 허용 목록에 오른 조직은 63곳이었습니다.

읽을 때 조심할 점이 둘 있습니다. 첫째, "실제 비밀"은 유효성을 확인한 값이 아닙니다. Apiiro는 어떤 자격 증명도 쓰거나 시험하지 않았고 어떤 호스트에도 접속하지 않았다고 밝혔습니다. 제공사 키 형식에 맞거나 공개 호스트와 같은 줄에 있는 비밀번호를 규칙으로 걸러 낸 뒤, 모든 출처를 합쳐 남은 값 2,774개를 별도 LLM 검토자가 가린 문맥으로 다시 봐서 둘 다 동의한 것만 셌습니다(전체 2,539개). 그러니 "작동하는 키 1,379개"라고 옮기면 틀립니다. 연락을 받은 조직 한 곳이 키가 살아 있었다고 확인해 줬다는 정도가 유효성에 대한 정보의 전부입니다. 둘째, 2,539개와 1,994개는 범위가 넓어진 합계라서 1,122개 파일과 바로 비교할 숫자가 아닙니다.

규칙이 많이 쌓인 큰 파일일수록 위험했습니다. Apiiro 집계로 8KB가 넘는 파일은 열 개 중 하나꼴로 비밀이 들어 있었고, 500바이트 미만은 500개 중 하나도 안 됐습니다. "다시 묻지 않기"를 오래 누를수록 규칙이 쌓이기 때문입니다. 비밀이 든 저장소의 중앙값을 보면 이 파일은 11월 2일 기준 217일 전에 처음 커밋됐고, 118개 저장소는 1년이 넘었습니다.

스캐너도 다섯 개 중 하나를 놓쳤다

비밀값 스캐너를 돌리면 되지 않느냐는 질문에, Apiiro 측정은 스캐너 하나는 절반쯤만 잡고 두 개를 함께 돌려도 다섯 개 중 하나는 놓친다고 답합니다. Apiiro는 104,185개 파일 전체에 gitleaks와 TruffleHog를 돌렸습니다(검증 기능은 끈 상태). 비밀이 든 1,122개 파일 중 gitleaks는 564개, TruffleHog는 643개를 잡았고, 215개는 둘 다 잡지 못했습니다(Apiiro).

놓친 이유는 형식입니다. 스캐너는 제공사 접두어가 붙은 긴 무작위 문자열을 찾습니다. PGPASSWORD=, sshpass -p, mysql -p 뒤에 친 비밀번호나 curl의 Bearer 헤더는 평범한 명령줄 속 평범한 단어라서 두 도구 모두 대부분 통과시켰다는 것이 Apiiro의 설명입니다.

GitHub의 기본 보호도 같은 한계를 안고 있습니다. GitHub는 공개 저장소에 비밀 탐지(secret scanning)를 무료로 자동 실행하고, 공개 저장소로 비밀을 푸시하지 못하게 막는 사용자용 푸시 보호를 기본으로 켜 둡니다(GitHub 비밀 탐지 문서, GitHub 푸시 보호 문서). 다만 기본 탐지 대상은 제공사와 파트너의 키 형식이고, 형식이 없는 비밀번호를 AI로 찾는 기능은 따로 켜야 합니다. 명령 속 비밀번호가 기본 설정에서 걸러진다고 기대하기는 어렵다는 것이 필자의 해석입니다.

Anthropic의 답변과 auto mode

Anthropic Claude Code 책임자 Boris Cherny는 11월 7일(미국 시간) 해커 뉴스에서 대책을 살펴보겠다고 답하면서도, 노출된 파일은 사람이 직접 만들어 커밋한 것이라고 봤습니다. 그는 "Claude Code는 지금까지 비밀값을 지우는 처리를 하지 않았다"며 막을 방법을 찾고 있다고 했고, auto mode가 이를 잡게 하는 방법과 기본적인 비밀 탐지를 넣는 방법을 후보로 들었습니다(해커 뉴스). 동시에 이 파일은 로컬에만 두는 파일이고 Claude가 만들 때 자동으로 git에서 제외하므로 이번 경우는 "수동으로 만들어 커밋한 것"이라고 했고, 권한 규칙 대신 auto mode를 쓰고 저장소 호스팅의 비밀 탐지를 켜라고 권했습니다.

데이터는 이 설명과 조금 다릅니다. Apiiro가 추적한 비밀이 든 저장소 1,105개 중 539개(49%)에서 Claude가 공동 작성자로 이름을 올린 커밋이 이 파일을 바꿨습니다(Apiiro). Apiiro는 Claude Code의 커밋 지침이 .env나 credentials.json은 커밋하지 말라고 하면서 자기 설정 파일은 목록에 넣지 않았다고 지적했습니다. 공동 작성 커밋이 있다고 해서 Claude가 그 파일을 처음 커밋했다는 증명은 아니므로, 어느 쪽 설명이 더 많은 사례에 맞는지는 이 숫자만으로 가릴 수 없습니다. 사용자들이 같은 문제를 2025년 8월부터 GitHub 이슈로 올렸는데(#5544, #11982, #13106, #91270) Anthropic이 답하지 않았고 세 건은 자동으로 닫혔다는 것도 Apiiro가 짚은 대목입니다. 11월 9일 필자가 다시 보니 네 건 모두 자동으로 닫힌 상태였고, #5544는 2025년 8월 11일 올라와 2026년 1월 3일 비활성으로 자동 종료돼 있었습니다(GitHub 이슈 #5544).

auto mode가 해법이라는 말은 절반만 맞습니다. 공식 문서에 따르면 2.1.283부터 터미널과 VS Code 대화형 세션은 auto mode로 시작하고, auto mode는 실제 자격 증명을 대화 기록이나 파일에 출력하는 일, 공개로 확인된 저장소로 비밀을 푸시하는 일을 기본으로 막습니다. 하지만 같은 문서는 auto mode가 "권한 확인을 줄일 뿐 안전을 보장하지는 않는다"고 적었습니다(Claude Code 권한 모드 문서). 해커 뉴스에서 auto mode도 민감한 명령은 묻고 그때 "항상 허용"을 고르면 저장된다는 지적이 나오자 Cherny도 "좋은 지적"이라고 인정했습니다.

필자 실험에서 auto mode는 가짜 비밀번호가 든 명령을 묻지 않고 실행해 규칙 파일을 만들지 않았습니다. 문서가 막는다고 한 것은 실제 자격 증명이라, 누가 봐도 가짜인 값은 막을 대상으로 보지 않았을 수 있습니다. 그래도 값이 사라지지는 않았습니다. 그 세션의 대화 기록 파일(Claude Code 설정 폴더의 projects 아래, 기본값은 ~/.claude/projects)을 찾아보니 가짜 비밀번호가 든 줄이 8개 있었습니다. 이 기록은 프로젝트 폴더 밖에 있어 그대로 git에 올라가지는 않습니다. 다만 Apiiro는 대화 기록을 내보내 저장소에 넣은 경우(.specstory, aider, Cursor 내보내기)에서도 2,523개 중 120개 파일에서 비밀을 찾았습니다. 명령에 비밀번호를 직접 치는 습관이 남아 있으면 어느 모드든 어딘가에 기록됩니다.

내 저장소 점검하는 법

점검은 저장소 루트에서 세 단계로 합니다. 파일 안의 값을 화면에 그대로 띄우지 않도록, 의심 줄은 개수와 앞부분만 보는 편이 안전합니다.

첫째, 파일이 지금 git에 추적되는지와 이 파일이 어떤 무시 규칙에 걸리는지 봅니다. 첫 명령에 파일 이름이 나오면 추적 중이고, 이때는 무시 규칙이 있어도 효과가 없어 둘째 명령도 아무것도 출력하지 않습니다. 추적 중이 아닌데 둘째 명령이 아무것도 출력하지 않으면 어떤 무시 규칙에도 걸리지 않은 상태이고, 전역 제외 파일 경로만 나오면 내 컴퓨터에서만 보호되는 상태입니다.

git ls-files .claude/settings.local.json
git check-ignore -v .claude/settings.local.json

둘째, 파일이 지금은 없어도 이력에 남은 적이 있는지 봅니다. 커밋이 하나라도 나오면 그 시점의 파일은 저장소 이력에 남아 있고, 그 커밋을 푸시했다면 원격 저장소와 포크, 클론에도 남아 있습니다.

git log --all --oneline -- .claude/settings.local.json

셋째, 허용 규칙에 비밀번호가 섞였는지 봅니다. 아래는 Apiiro가 스캐너가 놓친다고 꼽은 모양(PGPASSWORD=, sshpass -p, mysql -p, Bearer 헤더, 접속 문자열 안의 비밀번호)을 찾는 예입니다. 대소문자를 가리지 않고 --password=, MYSQL_PWD=, curl -u 사용자:비밀번호도 잡도록 넓혔고, 값이 화면에 뜨지 않도록 마지막 줄에서 줄 번호와 명령 이름만 남깁니다. jq가 필요하고, Windows에서는 WSL이나 Git Bash에서 돌립니다.

jq -r '.permissions.allow[]?' .claude/settings.local.json \
  | grep -inE 'passw|pwd=|sshpass -p|mysql .*-p[^ ]|bearer |-u [^ ]+:[^ ]+|://[^/ :@]+:[^@ ]+@|(token|secret|key)=' \
  | sed -E 's/^([0-9]+:[A-Za-z_]*\(?[A-Za-z_]*).*/\1 .../'

컴퓨터 전체를 보려면 작업 폴더 아래의 설정 파일을 모두 찾아 같은 검사를 돌립니다. 아래 ~/work는 내 작업 폴더 경로로 바꿉니다. 팀이 커밋하는 공유용 .claude/settings.json에도 같은 모양의 규칙이 들어갈 수 있어 함께 찾게 했습니다. 비밀번호 모양이 든 규칙 수와 파일 경로만 출력하고, 필자는 이 방식으로 저장소 121개를 점검했습니다.

find ~/work -path '*/.claude/settings*.json' -not -path '*/node_modules/*' 2>/dev/null \
  | while read -r f; do
      n=$(jq -r '.permissions.allow[]?' "$f" 2>/dev/null \
        | grep -icE 'passw|pwd=|sshpass -p|mysql .*-p[^ ]|bearer |-u [^ ]+:[^ ]+|://[^/ :@]+:[^@ ]+@|(token|secret|key)=')
      [ "$n" -gt 0 ] && echo "$n  $f"
    done

무언가 나왔다면 순서가 중요합니다. Apiiro는 "먼저 교체하고, 정리는 그다음"이라고 권합니다. 파일을 지워도 git 이력, 포크, 클론에 남은 사본은 사라지지 않기 때문입니다. 그 파일에 들어갔던 비밀번호와 토큰을 먼저 바꾸고, 그다음 규칙을 지우고 추적을 끊습니다.

echo '.claude/settings.local.json' >> .gitignore
git rm --cached .claude/settings.local.json
git commit -m "Stop tracking Claude Code local settings"

git rm --cached는 파일을 내 컴퓨터에서 지우지 않고 git 추적만 끊습니다(git rm 문서). 기존 .gitignore 끝에 줄바꿈이 없으면 echo로 붙인 줄이 마지막 줄에 이어 붙으니, 붙인 뒤 파일을 한 번 열어 확인합니다. 이력에 남은 값까지 지우려면 이력 재작성이 필요한데, 이미 공개된 비밀은 그래도 회수되지 않으므로 교체가 먼저입니다.

다시 생기지 않게 하는 권한 설정

핵심은 비밀번호를 명령에 직접 치지 않는 것과, 무시 규칙을 저장소에 넣는 것입니다. 나머지 설정은 이 둘을 돕는 장치입니다.

1. 저장소 .gitignore에 넣습니다. 전역 제외 목록은 내 컴퓨터에만 있으므로, 팀이 함께 쓰는 저장소라면 .claude/settings.local.json을 저장소 .gitignore에 넣어 커밋합니다. 그래야 동료 컴퓨터, 컨테이너, CI에서도 같은 규칙이 적용됩니다. Apiiro는 조직의 .gitignore 템플릿에 넣으라고도 권합니다.
2. 비밀은 변수로 참조합니다. PGPASSWORD=실제값 psql ... 대신 비밀 관리 도구나 셸 환경에 값을 두고 psql "$DATABASE_URL"처럼 이름으로 부르게 하면, 규칙에 남는 것은 변수 이름뿐입니다. Apiiro의 권고도 같습니다.
3. 규칙은 좁은 패턴으로 승인합니다. 권한 문서에 따르면 *가 없는 규칙은 정확히 그 명령 하나에만 맞고, *는 공백을 포함한 어떤 글자에도 맞습니다(Claude Code 권한 문서). 비밀이 든 긴 명령을 통째로 승인하는 대신 Bash(npm run test *)처럼 필요한 범위만 직접 적어 두면, 비밀도 남지 않고 curl *처럼 지나치게 넓은 허락도 피할 수 있습니다.
4. 승인 창에서 2번 문구를 읽습니다. 2.1.319의 승인 창은 2번 선택지에 저장될 규칙을 그대로 보여 줍니다. 그 문구에 비밀번호가 보이면 1번(이번만 허용)을 고르면 됩니다. Apiiro 그림처럼 긴 명령 속 비밀번호는 눈에 잘 띄지 않으니, 비밀이 든 명령은 처음부터 2번을 고르지 않는 습관이 낫습니다.
5. 스캐너는 보조로 둡니다. pre-commit이나 CI에서 비밀값 스캔을 돌리면 도움이 되지만, 위에서 본 것처럼 명령 속 비밀번호는 기본 규칙으로 잘 잡히지 않습니다. .claude/ 같은 에이전트 폴더를 .env처럼 다루고, 명령 속 비밀번호 모양을 잡는 규칙을 더하라는 것이 Apiiro의 제안입니다.

공유용 .claude/settings.json도 같은 눈으로 봐야 합니다. 이 파일은 팀이 일부러 커밋하는 파일인데, Apiiro가 확인한 공개 사본 76,011개 중 298개에서 비밀이 나왔고 대부분 허용 규칙 속 명령줄이었습니다. 팀 규칙에는 비밀이 들어갈 이유가 없으니 리뷰 때 허용 목록을 한 번씩 읽어 보는 편이 좋습니다. 확장과 공급망 쪽 위험은 클로드 코드 확장 사고 정리에서 다뤘습니다.

출처

1. Claude Code 설정 문서: code.claude.com/docs/en/settings
2. Claude Code 권한 문서: code.claude.com/docs/en/permissions
3. Apiiro: apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
4. git gitignore 문서: git-scm.com/docs/gitignore
5. 해커 뉴스: news.ycombinator.com/item?id=50407882
6. 달레 코딩: daleseo.com/claude-code-settings
7. GitHub 비밀 탐지 문서: docs.github.com/en/code-security/secret-scanning/introduction/about-sec…
8. GitHub 푸시 보호 문서: docs.github.com/en/code-security/secret-scanning/introduction/about-pus…
9. GitHub 이슈 #5544: github.com/anthropics/claude-code/issues/5544
10. Claude Code 권한 모드 문서: code.claude.com/docs/en/permission-modes
11. git rm 문서: git-scm.com/docs/git-rm