어제 저는 관리 설정이 없는 장비에서 거부 규칙을 무효화하는 7줄 모드에 대해 글을 썼습니다. 밤사이 Claude Code 2.1.289가 출시되었고 (10월 3일), 그 변경 로그는 마치 제가 다루었던 문제 유형에 대한 직접적인 답변처럼 보였습니다. 규칙을 무효화하고 요청하는 규칙 중 제대로 작동하지 않았던 네 가지 별도의 수정 사항이 있었습니다. 안심하기 전에 두 가지를 확인해야 합니다. 네 가지 수정 사항 중 하나는 관리 장비에서만 적용됩니다. 그리고 실제로 실행되는 빌드는 어떤 npm 채널을 추적하느냐에 따라 달라지는데, 오늘 아침 레지스트리를 확인해 보니 채널이 분리되어 있었습니다.

실제로 패치된 내용

변경 로그에서 가져온 네 가지 강제 적용 누락 사항:

1. 복합 셸 명령어의 중첩된 부분에 대한 거부 또는 요청 규칙은 관리 장비에서 사용자 설치 모드의 승인보다 우선합니다.
2. Read 거부 규칙은 이제 심볼릭 링크를 통해 IDE에서 @로 언급되거나, 변경되었거나, 선택된 파일에도 적용됩니다. 확인 시 실제 경로를 먼저 결정한 후 판단합니다.
3. Bash 거부 및 요청 규칙은 샌드박스가 자동으로 명령을 허용할 때, TZ="$HOME" rm -rf build와 같이 환경 변수 접두사 뒤에 확장된 값을 가진 명령어도 포착합니다.
4. 명령어 앞에 단순한 변수 할당이 오는 경우, Bash 거부 또는 요청 규칙은 샌드박스 자동 허용 하에서도 더 이상 건너뛰지 않습니다.

2.1.288 버전에서 하루 전에 나온 다섯 번째 관련 수정 사항도 있습니다: bash -c 또는 sh -c 스크립트 내에서 / 또는 홈 디렉터리에서의 위험한 rm이 프롬프트 없이 bypassPermissions 모드나 셸 허용 규칙 하에서도 실행되던 문제였습니다 (anthropics/claude-code#96300). 같은 질병, 다른 벡터: 규칙은 존재했지만 파서가 도달하지 못했던 것입니다.

관리 장비의 별표

첫 번째 수정 사항은 모드 스토리와 연결되며 중요한 제한 사항을 갖고 있습니다. "관리되는 머신(managed machines)"이란 Team 또는 Enterprise 로그인, 혹은 관리 설정이 적용된 머신을 의미합니다. 바로 이곳에 cc-plugin-sec-default 가드(guard)가 이미 자리 잡고 있는 곳입니다. 개별 개발자가 가장 많이 사용하는, 관리 설정이 없는 Pro 또는 Max 머신의 경우 이 수정 사항의 보호를 받지 못합니다. 어제 감사에서 나온 모드 오버라이드 경로(mod-override path)는 여전히 열려 있으며, 완화 조치(mitigations)는 다음과 같습니다: 단일 세션에는 --safe-mode, 모든 세션에는 "disableAllHooks": true, 또는 API 키 실행 시에는 --bare를 사용해야 합니다.

Anthropic에게 비난조로 접근하기보다는 공정하게 전달하고 싶습니다. 관리되는 머신부터 격차를 줄여나가는 것은 조직이 가장 큰 피해 범위(blast radius)를 지니고 있기 때문에 방어 가능한 순서 선택입니다. 하지만 만약 헤드라인 "이제 규칙은 모드를 거부한다"만 읽고 단독 Pro 플랜을 사용한다면, 귀하의 머신에 대해서는 사실이 아닌 결론을 내릴 수 있습니다.

현재 빌드 확인하기

여기서 실질적인 내용이 나옵니다. 오늘 아침 npm 레지스트리를 조회해 보니 dist-tags는 다음과 같습니다:

stable: 2.1.285
latest: 2.1.289

안정(stable) 채널은 네 개의 빌드만큼 뒤처져 있으며, 이러한 수정 사항뿐만 아니라 모드 자체보다도 오래된 버전입니다 (2.1.287). 만약 @anthropic-ai/claude-code@stable로 설치했거나 패키지 관리자가 해당 태그를 고정했다면, 어제 나온 어떤 수정 사항도 귀하의 디스크에 존재하지 않습니다. 다음 명령어로 확인하세요:

claude --version
npm view @anthropic-ai/claude-code dist-tags

제가 사용하는 호스트는 NixOS를 통해 2.1.268 버전을 실행하고 있으며, 이는 훨씬 더 뒤처진 버전입니다. 저의 사용 목적에는 문제가 없지만, 여기서 제 규칙이 어떤 역할을 하는지 추론할 때 2.1.28x 버전의 동작에 의존할 수 없다는 의미입니다. 변경 로그 항목을 신뢰하기 전에 반드시 버전을 확인하십시오.

직접 우회 경로 재현해 보기

권한 수정 사항과 관련하여 정직하게 접근하는 방법은 자신의 머신에서 자신의 규칙으로 이를 테스트해보는 것입니다. 비용이 전혀 들지 않는 세 가지 간단한 탐색(probes)을 수행하세요:

symlink 검사: Read 거부 규칙이 링크를 통과할 수 있나요?

ln -s ~/.env /tmp/envlink

그런 다음 IDE에서 @-mention /tmp/envlink를 하고 프롬프트를 기다립니다.

...

2.1.289 버전에서는 세 가지 모두에서 거부(denial)가 발생해야 합니다. 이전 빌드에서는 두 번째와 세 번째는 통과할 수 있으며, 첫 번째는 파일이 모델에 도달하는 방식에 따라 달라집니다. 만약 오래된 빌드에서 검사가 통과하더라도 당황할 필요는 없으며, 업데이트하거나 보완 규칙을 추가해야 할 이유입니다.

거부 규칙이 실패하는 이유

거부 규칙은 방화벽이 아닙니다. 이는 명령의 파싱된 표현에 대한 패턴 매칭이며, 셸(shell)은 인접하지만 동일하지 않은 무언가를 실행합니다. 환경 변수 접두사(Environment-variable prefixes), 단순 할당(bare assignments), 중첩 복합 명령어(nested compound commands), 그리고 심볼릭 링크(symlinks)는 모두 파서가 본 것과 셸이 실행한 것 사이에 간극을 만듭니다. 이번 릴리스의 모든 수정 사항은 규칙 확인 전에 명령의 더 많은 부분을 해결함으로써 이 간극을 좁힙니다: 심볼릭 링크에 대한 실제 경로, 접두사에 대한 확장된 값, 복합 명령어에 대한 중첩 부분입니다. 릴리스가 거듭될수록 이 간극이 계속 좁혀질 것으로 예상하고, 그 사이에 새로운 벡터(vectors)가 나타날 것이라고 예상해야 합니다. 왜냐하면 셸은 어떤 파서도 가지고 있지 않은 더 많은 형태를 가지고 있기 때문입니다.

그동안 규칙에 무엇을 넣어야 할까요

빌드가 수정 사항을 반영하기 전까지는 두 가지 방어 패턴이 도움이 됩니다. 명령어를 거부할 때 인터프리터도 거부해야 합니다 (Bash(bash -c:*)와 같은 위험한 동사들). 왜냐하면 래퍼 스크립트가 정확한 우회 경로 중 하나였기 때문입니다. 또한, 허용 규칙을 거부 규칙과 동일하게 의심해야 합니다. 2.1.288의 rm 수정 사항이 보여주듯이, 허용 규칙은 샌드박스가 실수로 통과시키는 범위를 넓힐 수 있기 때문입니다. 이는 우리가 설정 파일에 무엇이 속하는지 대 후크(hooks)에 무엇이 속하는지를 결정할 때 적용하는 것과 같은 원칙이며, 이것이 2.1.282에서 클론된 리포지토리 설정에 대한 방어(fencing)가 중요했던 이유이었습니다. 설정의 모든 계층은 누군가 감사를 해야 하는 공격 표면(attack surface)입니다.

코드로 권한 설정을 테스트하기

제가 계속 접하게 되는 패턴은 다음과 같습니다: 권한 규칙은 구조를 지탱하는 설정(load-bearing config)이며, 대부분의 팀은 이에 대한 부정 테스트(negative test)를 작성하지 않습니다. 변경 로그 자체가 테스트 케이스의 원천이 됩니다. 왜냐하면