Claude Code settings.local.json 비밀번호 노출 확인하는 법

Claude Code가 명령을 실행해도 되냐고 물을 때 "Yes, and don't ask again"을 눌러 본 적 있나요? 그 명령은 글자 그대로 프로젝트의 .claude/settings.local.json에 저장돼요. 명령 안에 비밀번호나 토큰이 있었다면 그것도 같이요.

보안 회사 아피로(Apiiro)가 2026년 11월 초에 이 문제를 공개했어요. 공개 GitHub 저장소에서 비밀값이 든 이 파일을 1,122개 찾았다고 해요. 저는 이게 Claude Code를 쓰는 사람이라면 한 번은 직접 확인해 봐야 할 일이라고 봐요. 이 글을 읽으면 내 파일을 확인하는 법, 이미 올라갔을 때 할 일, 앞으로 안 남기는 습관을 챙길 수 있어요.

settings.local.json에 왜 비밀번호가 저장되나요?

"다시 묻지 않기"를 고르면 Claude Code는 허용 규칙(allow rule, 묻지 않고 실행해도 되는 명령 목록)을 하나 만들어요. 공식 문서 기준으로 Bash 명령은 저장소와 명령마다 영구히 저장돼요.

규칙의 모양은 질문 창이 제시한 대로예요. npm test *처럼 패턴일 때도 있고, 명령 한 줄 전체일 때도 있어요. 명령 전체가 저장되면 그 안의 값도 그대로 남아요.

{
  "permissions": {
    "allow": [
      "Bash(PGPASSWORD=실제비밀번호 psql -h db.example.com -U admin)"
    ]
  }
}

위는 이해를 돕기 위한 예시예요. 데이터베이스 접속이나 배포 명령을 Claude에게 맡기다 보면 이런 줄이 쉽게 생겨요.

Claude Code도 이 파일을 git에서 빼려고 해요. 처음 만들 때 내 컴퓨터의 전역 git 제외 목록에 추가하거든요. 문제는 이 설정이 내 컴퓨터에만 있다는 점이에요. 다른 컴퓨터에서 클론하거나, 이미 커밋된 파일에는 소용이 없어요. 저장소의 .gitignore에는 따로 넣어 주지 않아요.

내 저장소에 올라갔는지 어떻게 확인하나요?

프로젝트 폴더에서 아래 두 줄부터 실행해 보세요.

# 지금 git이 이 파일을 추적하고 있는지
git ls-files .claude/settings.local.json
 
# 예전에라도 커밋된 적이 있는지
git log --all --oneline -- .claude/settings.local.json

둘 다 아무것도 안 나오면 이 저장소에는 올라간 적이 없어요. 하나라도 결과가 나오면 다음 단계로 가세요.

팀이나 조직 단위라면 GitHub 코드 검색에서 path:.claude/settings.local.json org:조직이름으로 찾을 수 있어요. 팀이 일부러 커밋하는 .claude/settings.json도 같이 보세요. 아피로는 이 공유 파일의 허용 규칙에서도 비밀값을 찾았어요.

비밀값 검사 도구만 믿으면 안 돼요. 아피로가 돌려 본 결과, 두 유명 도구가 모두 놓친 파일이 215개였어요. 대부분 PGPASSWORD=나 sshpass -p 뒤에 쓴 평범한 비밀번호였어요. 그래서 저는 파일을 직접 열어서 allow 목록을 한 줄씩 읽는 게 가장 확실하다고 봐요.

이미 올라갔다면 무엇부터 해야 하나요?

순서가 중요해요. 비밀번호 교체가 먼저, 파일 정리는 그다음이에요.

1. 파일에 있던 비밀번호, 토큰, 키를 모두 새것으로 바꿔요. 예전 커밋에만 있던 값도 포함이에요.
2. git rm --cached .claude/settings.local.json으로 git 추적만 끊어요. 내 컴퓨터의 파일은 남아요.
3. 저장소의 .gitignore에 **/.claude/settings.local.json을 추가하고 커밋해요.
4. 내 컴퓨터의 파일을 열어 비밀값이 든 규칙을 지워요.

파일을 지우는 것만으로는 끝나지 않아요. 예전 커밋과 포크(fork, 다른 사람이 복사해 간 저장소)에는 그대로 남거든요. 공개 저장소였다면 이미 누가 봤다고 가정하는 게 안전해요.

커밋을 Claude가 했을 수도 있어요. 아피로가 추적한 저장소의 절반 가까이에서 Claude가 공동 작성자로 표시된 커밋이 이 파일을 바꿨대요. "나는 올린 적 없는데"라는 기억만 믿지 말고 위 명령으로 확인하세요.

앞으로 비밀번호를 안 남기려면 어떻게 하나요?

제가 지키는 습관은 세 가지예요.

• 비밀값은 변수로 넘겨요. 명령에 비밀번호를 직접 쓰지 말고 $DB_URL처럼 환경 변수를 쓰게 해요. 그러면 규칙에는 변수 이름만 남아요.
• 패턴으로 승인해요. 질문 창이 npm test * 같은 패턴을 제시할 때만 "다시 묻지 않기"를 눌러요. 비밀값이 든 한 줄짜리 명령은 이번만 허용해요.
• 규칙을 가끔 청소해요. /permissions를 열면 저장된 규칙을 보고 지울 수 있어요.

저는 이 문제의 본질이 "편해서 누른 버튼이 영구 기록이 된다"는 데 있다고 봐요. 권한 규칙 문법과 패턴 쓰는 법은 Claude Code Auto 모드 가이드에 정리해 뒀어요. 설정 파일이 몇 개고 어디에 있는지는 Claude Code settings.json 위치와 설정법을 보세요.

2026년 11월 12일 기준 Claude Code 변경 기록(2.1.322까지)에는 이 저장 방식을 바꾼 수정이 아직 없어요. 고쳐지기 전까지는 위 습관이 가장 현실적인 방어예요.

자주 묻는 질문

settings.local.json을 지워도 되나요?

지워도 Claude Code는 정상 작동해요. 저장해 둔 허용 규칙이 사라져서 명령마다 다시 물어볼 뿐이에요. 다만 이미 커밋된 적이 있다면 지우기 전에 비밀번호부터 바꾸세요.

공개 저장소가 아니면 괜찮은가요?

덜 위험할 뿐 괜찮지는 않아요. 비공개 저장소도 팀원 모두가 볼 수 있어요. 이 파일은 npm 패키지, Docker 이미지, 압축 파일, 동기화 폴더에 섞여 나갈 수도 있어요.

Codex에도 같은 문제가 있나요?

아피로가 문서를 비교한 코딩 에이전트 16개 중에서 승인한 명령 전체를 프로젝트 파일에 기본 저장한다고 확인된 건 Claude Code뿐이었어요. Codex의 승인 설정은 Codex config.toml 위치와 설정 정리에서 볼 수 있어요.

Auto 모드를 쓰면 이 문제가 없나요?

Auto 모드는 묻는 횟수를 줄여 주지만, 이미 저장된 규칙을 지워 주지는 않아요. 예전에 "다시 묻지 않기"로 만든 규칙이 있다면 따로 확인해야 해요.

참고 문서: Claude Code Configure permissions · Claude Code Settings files and precedence · The Hacker News 보도 (2026년 11월 7일)