Claude Code에서 명령 실행 권한을 세밀하게 설정해 사용한다면, 이번에는 업데이트 채널과 실제 실행 버전을 함께 확인할 필요가 있다. Anthropic이 2026년 10월 3일 공개한 Claude Code 2.1.289에는 특정 조건에서 Bash의 차단·승인 요청 규칙이 적용되지 않던 문제의 수정이 포함됐다. 자동 업데이트를 켜 두었는지만 확인하면, 필요한 수정이 현재 세션에 들어왔는지 놓칠 수 있다.
이 글은 10월 5일 확인한 공식 릴리스 노트와 문서를 기준으로 수정 범위, 채널 선택, 설치 확인 순서를 정리한다. 위험한 삭제 명령을 직접 재현한 테스트 결과는 포함하지 않는다.
이번 수정이 적용되는 조건
공식 변경 로그가 설명하는 핵심 조건은 샌드박스의 auto-allow다. 이 상태에서 명령 앞에 값이 확장되는 환경 변수 설정이 붙거나, 단순한 변수 대입이 먼저 나오면 뒤에 있는 명령에 Bash의 deny 또는 ask 규칙이 제대로 적용되지 않는 경우가 있었다. deny는 실행을 막고, ask는 실행 전에 승인을 요청하는 규칙이다.
같은 버전에는 관리형 장비에서 복합 셸 명령의 내부 명령에 걸린 규칙이 사용자 설치 Mod의 승인보다 우선하지 않던 문제, 심볼릭 링크를 통해 IDE에서 언급·변경·선택한 파일에 Read 차단 규칙이 적용되지 않던 문제도 포함됐다. 각 항목에는 서로 다른 조건이 있으므로 이를 모든 명령과 모든 설치 환경에 공통으로 발생하는 문제라고 확대해 읽어서는 안 된다.
공개 기록으로 확인되는 것은 이러한 수정 범위다. 피해 규모나 실제 악용 여부는 이 변경 로그만으로 단정할 수 없다. 버전 번호와 적용 조건을 함께 읽는 것이 정확하다. Anthropic 공식 변경 로그
auto-allow와 일반 권한 모드 구분하기
샌드박스는 셸 명령이 접근할 수 있는 파일과 네트워크의 경계를 정한다. auto-allow는 그 경계 안에서 실행되는 명령을 자동 승인하는 방식이다. 샌드박스의 regular permissions 방식은 샌드박스 경계를 유지하면서 명령을 기존 권한 처리 과정에 보낸다. 두 모드는 승인 방식이 다르며, 파일·네트워크 제한 자체는 같다.
현재 상태는 Claude Code 세션에서 /sandbox를 열어 살펴볼 수 있다. Mode에서 승인 방식을, Config에서 적용된 설정을 확인한다. 당장 업데이트하기 어려운 환경이라면 regular permissions 사용을 검토할 수 있다. 다만 이 선택을 모든 권한 관련 문제의 해결책으로 간주하거나, 샌드박스 자체를 꺼서 대응할 이유는 없다.
특히 auto-allow와 Claude Code의 별도 기능인 Auto mode는 구분해야 한다. 전자는 샌드박스 경계를 근거로 Bash 실행을 자동 승인하고, 후자는 분류기가 작업을 검토하는 권한 모드다. 설정 화면에서 ‘자동’이라는 단어만 보고 동일한 기능이라고 판단하면 점검할 대상을 잘못 잡을 수 있다.
공식 문서에는 auto-allow에서도 명시적인 차단 규칙과 내용 범위를 지정한 ask 규칙이 적용된다고 설명돼 있다. 이번 수정은 그 약속이 특정 셸 명령 형태에서도 지켜지도록 하는 변경으로 이해하면 된다. 공식 샌드박스 모드 설명
stable 표시보다 실행 버전 확인하기
공식 문서에서 latest는 새 릴리스를 바로 받는 기본 채널이고, stable은 큰 회귀 문제가 있는 릴리스를 건너뛰며 통상 약 일주일 지난 버전을 제공하는 채널이다. 따라서 stable이라는 이름만으로 특정 수정의 포함 여부를 판단할 수 없다. 채널이 가리키는 버전은 계속 바뀌므로 과거 기사에 나온 숫자를 현재 상태로 받아들이는 것도 피해야 한다.
- 터미널에서
claude --version을 실행해 현재 버전을 기록한다. claude doctor로 설치 상태, 설정 오류와 최근 업데이트 진단을 확인한다.- 네이티브·npm 설치라면 세션의
/config에서 Auto-update channel을 확인한다. - 선택한 채널과 조직 정책을 확인한 뒤
claude update로 갱신한다. - Claude Code를 다시 시작하고 버전을 재확인한다. 백그라운드 업데이트는 다음 시작부터 적용된다.
Homebrew·WinGet·Linux 패키지 관리자로 설치했다면 해당 관리자의 업데이트 경로를 사용한다. Homebrew는 설치한 cask가, Linux 저장소 설치는 선택한 저장소가 채널을 결정한다. 업데이트 성공 메시지와 실제로 실행되는 버전까지 함께 확인해야 점검이 끝난다. 필요한 수정이 선택한 채널에 아직 없다면, 관리자는 latest 이동이나 특정 버전 배포를 검토할 수 있다. 공식 업데이트 안내
권한 규칙은 어느 파일에서 왔는지도 확인하기
버전을 확인했다면 /permissions에서 현재 규칙을 살펴보자. 이 화면은 규칙 목록과 각 규칙이 나온 settings.json 파일을 보여 준다. 실제로 적용되는 설정을 읽어야 사용자 설정과 프로젝트 설정을 혼동하지 않는다. 회사에서 관리하는 환경이라면 관리 정책 담당자와 함께 확인하는 편이 좋다.
일반적인 권한 규칙의 평가 순서는 deny, ask, allow다. 하지만 Mod까지 포함하면 환경과 정책에 따른 추가 조건이 있으므로, 이번 릴리스가 모든 Mod의 권한 동작을 동일하게 바꾸었다고 해석할 수는 없다. 중요한 것은 자신의 실행 환경에서 어떤 규칙과 정책이 적용되는지 확인하는 일이다.
프롬프트나 CLAUDE.md에 “삭제하지 마라”라고 적는 것과 실행 권한을 설정하는 것도 구분해야 한다. 전자는 모델이 시도할 행동에 영향을 주고, 실제 접근 허용·차단은 Claude Code의 권한 설정으로 관리한다. 파일에 적힌 요청만 보고 차단이 구성됐다고 판단하지 말고 권한 화면을 확인하자. 공식 권한 관리 설명
이번 업데이트를 적용할 때 남길 기록
팀 단위로 배포한다면 확인한 날짜, 이전 버전, 업데이트 후 버전, 사용 채널과 설치 방식을 짧게 남겨 두면 좋다. 문제가 생겼을 때 “최신 버전으로 업데이트했다”는 말보다 어느 환경에서 무엇이 실행됐는지 훨씬 분명하게 설명할 수 있다.
실제 프로젝트에서 삭제 명령을 실행해 수정 여부를 시험할 필요는 없다. 우선 공식 릴리스에 명시된 버전을 설치했는지 확인하고, 평소 사용하는 비파괴 작업이 정상 동작하는지 점검하자. 별도 회귀 검증이 필요하다면 중요 파일이 없는 격리 환경과 가짜 데이터로 수행하는 편이 안전하다.
이번 변경에서 가져갈 실무적인 결론은 간단하다. 현재 버전, 업데이트 채널, 샌드박스 승인 방식, 실제 권한 규칙을 함께 확인하자. 네 항목이 확인돼야 “업데이트가 적용됐다”는 말을 자신의 작업 환경에 맞게 판단할 수 있다.
자료 확인: 2026년 10월 5일 15:34 KST. Google Alerts에서 발견한 MIXED의 10월 5일 보도를 단서로 공식 문서를 교차 확인하고 AI의 도움을 받아 정리했다. 알림 화면의 10월 4일 표시는 소프트웨어 출시일과 구분했다.
댓글
댓글 쓰기