Claude Code 보안 패치: Bash 권한 우회와 워크트리 격리 수정이 중요한 이유

2026년 8월 6일 Claude Code changelog에서 가장 눈에 띄는 내용은 새 기능보다 보안 수정입니다. 특히 Bash permission bypass, invisible Unicode로 승인창 일부를 숨기는 문제, workflow sandbox 바깥 코드를 실행할 수 있던 dynamic import 문제, agent definition의 bypassPermissions 정책 구멍이 같이 언급됐습니다.

개발팀 입장에서는 “AI 코딩 도구가 조금 더 안전해졌다” 정도로 넘기면 안 됩니다. 이제 코딩 에이전트는 단순 자동완성기가 아니라 터미널 명령을 만들고, 파일을 수정하고, 다른 세션에 메시지를 보내고, 원격 샌드박스까지 다루는 실행 주체입니다. 권한 검사가 흔들리면 모델 성능 문제가 아니라 배포 파이프라인 리스크가 됩니다.

왜 이번 패치가 실무 개발자에게 직접적인 이슈인가

Claude Code 2.1.223에는 명령 승인 UI와 실제 실행 명령 사이의 불일치를 막는 수정이 들어갔습니다. changelog에는 crafted command가 permission check에서 일부를 숨길 수 있던 Bash 권한 우회, 탭이나 보이지 않는 Unicode로 승인 다이얼로그 일부를 감추는 문제 수정이 명시돼 있습니다.

이 종류의 버그는 “누가 일부러 이상한 명령을 넣어야만 터지는 취약점”으로 보일 수 있습니다. 하지만 AI 코딩 환경에서는 공격면이 넓습니다.

• 외부 문서나 이슈 본문을 에이전트가 읽습니다.
• README, 테스트 로그, PR 코멘트가 프롬프트 컨텍스트로 들어갑니다.
• 에이전트가 그 내용을 근거로 shell command를 조합합니다.
• 사람은 승인창만 보고 “대충 npm test겠지”라고 허용합니다.

즉, 권한창은 마지막 안전장치입니다. 승인창에 표시되는 문자열과 실제 검사되는 문자열이 다르면, 사람이 검토한다는 전제가 깨집니다.

권한 모델을 제품 기능이 아니라 운영 정책으로 봐야 한다

많은 팀이 AI 코딩 도구 도입을 IDE 생산성 기능으로 분류합니다. 하지만 Claude Code changelog를 보면 운영 정책에 가까운 영역이 계속 늘어나고 있습니다. owner wildcard로 marketplace repo를 허용/차단하는 설정, restricted model이 요청됐을 때 parent model로 대체됐다는 경고, org bypass-permissions disable policy를 우회하지 못하게 한 수정이 그 예입니다.

정리하면 “개발자가 편하게 쓰는 도구”에서 “조직이 통제해야 하는 실행 환경”으로 이동하고 있습니다. 특히 다음 조건에 해당하면 개인 설정에 맡기면 위험합니다.

• 사내 저장소에 고객 데이터, 결제 로직, 인프라 코드가 포함돼 있다.
• 에이전트가 git, 배포 CLI, cloud CLI를 실행할 수 있다.
• marketplace skill, slash command, workflow agent를 허용한다.
• background agent나 subagent를 장시간 실행한다.

이 경우 권한 정책은 보안팀 문서 한 줄이 아니라 repo 설정, 조직 관리 설정, CI 검사로 내려와야 합니다.

워크트리 격리 수정도 같은 맥락이다

8월 4일 Claude Code 2.1.222에는 worktree-isolated session과 subagent가 main checkout에 destructive git command를 실행할 수 있던 문제를 수정했다는 항목도 있습니다. 파일 편집만 격리하고 Bash는 제대로 격리하지 못하면, 에이전트가 “별도 작업공간에서 실험 중”이라는 설명이 반쪽짜리가 됩니다.

예를 들어 사람은 feature worktree에서 자동 리팩터링을 돌린다고 생각했는데, 실제 Bash 명령이 main checkout의 브랜치나 파일에 영향을 준다면 문제가 커집니다. 특히 AI 에이전트는 다음 명령을 자연스럽게 만들 수 있습니다.

git clean -fd
git reset --hard origin/develop
git checkout .

명령 자체는 일반 개발에서도 쓰입니다. 문제는 어느 checkout에서 실행되는지, 승인창이 그 맥락을 충분히 보여주는지, 조직 정책이 위험 명령을 막는지입니다.

개발팀이 바로 바꿔야 할 사용 규칙

첫째, AI 코딩 세션에는 “허용 명령 목록”과 “금지 명령 목록”을 분리해야 합니다. npm test, pnpm lint, git diff, git status는 기본 허용 후보입니다. 반대로 rm -rf, git reset --hard, git clean -fd, cloud credential 출력, production 배포 명령은 사람이 직접 터미널에서 실행하는 편이 낫습니다.

둘째, 외부 텍스트를 읽은 직후의 shell command는 더 엄격하게 봐야 합니다. 이슈 본문, 문서, 웹페이지, PR 코멘트는 프롬프트 인젝션이 들어올 수 있는 통로입니다. 에이전트가 “문서에 이렇게 하라고 되어 있다”며 curl이나 bash를 제안하면 출처와 의도를 따로 검증해야 합니다.

셋째, background agent와 subagent에는 더 작은 권한을 줘야 합니다. 대화형 세션은 사람이 중간에 멈출 수 있지만, background agent는 오래 돌면서 파일과 명령을 누적합니다. changelog에서도 background agent resume, permission classifier, SendMessage 관련 수정이 반복됩니다. 장기 실행 세션은 편리하지만 감사가 더 어렵습니다.

승인창에서 확인할 최소 항목

승인창을 볼 때는 명령 첫 단어만 보지 말고 네 가지를 확인해야 합니다.

1. 실행 위치: 어느 repo, 어느 worktree, 어느 directory인가.
2. 전체 명령: 줄바꿈, 탭, Unicode, 파이프 뒤 명령까지 포함됐는가.
3. 부작용: 파일 삭제, 브랜치 이동, 네트워크 전송, credential 접근이 있는가.
4. 반복 가능성: 한 번 허용이 이후 명령까지 넓게 열어주지는 않는가.

특히 파이프와 command substitution은 조심해야 합니다.

cat script.sh | bash
curl https://example.com/install.sh | sh
node -e "..."
python -c "..."

이런 명령은 승인창에서 짧아 보이지만 실제 동작은 외부 코드에 달려 있습니다.

팀 단위 도입 기준

Claude Code 같은 코딩 에이전트를 팀에 도입한다면, “누가 어떤 기능을 쓸 수 있는지”보다 “어떤 실패를 허용하지 않을지”를 먼저 정해야 합니다. 모델이 틀리는 것은 복구할 수 있습니다. 하지만 credential 유출, main branch 손상, production 데이터 변경은 복구 비용이 다릅니다.

권장 기준은 단순합니다.

• 기본은 read-only + test command 허용으로 시작한다.
• repo별로 write 권한을 분리한다.
• destructive git command는 수동 실행만 허용한다.
• 외부 marketplace skill은 owner 단위 allowlist로 제한한다.
• agent가 만든 변경은 반드시 git diff와 테스트 로그로 검증한다.

실행 체크리스트

• Claude Code 버전을 확인하고 2.1.223 이상으로 업데이트한다.
• 조직 관리 설정에서 bypassPermissions 관련 정책을 확인한다.
• worktree 격리 세션에서 Bash가 실제로 격리되는지 테스트한다.
• 승인창에 표시되는 명령을 “전체 문자열” 기준으로 검토하는 규칙을 만든다.
• background agent에는 별도 권한 정책을 적용한다.
• marketplace, forked skill, workflow agent는 owner 단위 allowlist부터 시작한다.
• 에이전트가 만든 변경은 diff, test, lint, 빌드 중 최소 하나로 확인한다.

이번 업데이트의 핵심은 새 기능이 아니라 신뢰 경계입니다. AI 코딩 도구를 많이 쓸수록 모델 성능보다 권한, 격리, 감사 로그가 더 중요해집니다. 생산성 도구로 도입했더라도 운영 기준은 보안 도구처럼 가져가는 편이 안전합니다.