Claude Code 자동 승인: 권한 우회 설정과 더 안전한 대안

권한 우회 플래그는 정확히 무엇을 해제할까요?

--dangerously-skip-permissions와 --permission-mode bypassPermissions는 같은 모드를 선택합니다. Claude는 파일 변경, 셸 명령 등 각종 툴 호출을 진행하면서 통상적인 승인을 기다리지 않습니다. 보호 경로에 대한 쓰기도 허용됩니다. 대화형으로 처음 실행하면 사용자의 책임을 알리는 경고가 표시되며, 동의하지 않으면 Claude Code가 종료됩니다. Anthropic의 권한 우회 문서

권한은 작업장의 승인 창구, 격리는 작업장을 둘러싼 벽이라고 생각하면 이해하기 쉽습니다. 승인 창구를 없앤다고 벽이 생기지는 않습니다. 작업이 중단되지 않는다는 이점은 있지만, 잘못된 동작이 실행되기 전에 발견하고 막을 기회를 잃습니다.

따라서 작업 방식도 달라집니다. 개별 동작을 그때그때 승인하는 대신, 먼저 실행 환경을 정하고 작업이 끝난 뒤 결과를 검토해야 합니다. 그렇다고 코드의 정확성이 보장되거나 악의적인 지시가 무해해지는 것은 아닙니다.

권한 우회 모드에서도 유지되는 제어는 무엇일까요?

이름에 ‘skip’이 들어간다고 모든 제어가 사라지는 것은 아닙니다. 무인 실행을 예상했는데 작업이 멈추거나 거부된다면 다음 차이를 확인해야 합니다.

마지막 행에 해당하는 정확한 읽기 설정은 permissions.blockReadsOutsideWorkingDirectories: true입니다. 파일을 읽는 것으로 인식되는 Bash 명령은 허용된 디렉터리 밖에서 여전히 승인 요청을 띄울 수 있습니다. 샌드박스가 강제하는 차단은 이와 다르게 동작합니다. 비대화형 -p 권한 우회 실행에서는 여전히 승인 요청이 필요한 호출을 사용자에게 묻는 대신 거부합니다. 어떤 모드에서도 자동 승인하지 않는 작업, 작업 디렉터리 밖의 읽기 설정

차단 기능을 수행하는 PreToolUse 훅도 툴 승인 과정에 계속 관여합니다. EndConversation에는 특별한 예외가 있습니다. 사용할 수 있는 다른 툴이 남아 있으면 deny와 ask 규칙으로 이 툴을 제한할 수 없습니다. 설치된 mod는 관리형 정책으로 지정되지 않은 일부 권한 결정을 덮어쓸 수 있으므로, 팀에서 반드시 지켜야 할 제어는 관리형 정책에 넣어야 합니다. 관리자는 "permissions": {"disableBypassPermissionsMode": "disable"}로 권한 우회를 금지할 수 있습니다. --restricted로 시작한 세션도 권한 우회 모드를 거부합니다. 훅과 규칙의 우선순위, 권한 우회 비활성화 설정

권한 우회 모드에서는 보호 경로에도 쓸 수 있습니다

.git이나 .claude를 수정할 때 여전히 확인 창이 뜰 것이라고 생각하면 안 됩니다. 권한 우회 모드에서는 보호 경로에 쓰기가 허용됩니다. 앞서 설명한 중요 디렉터리 삭제 검사와는 별개의 동작입니다.

Anthropic이 지정한 보호 경로에는 다음이 포함됩니다.

.claude 내부에는 범위가 한정된 예외가 있습니다. Claude 자체 워크트리, 현재 계획 파일, 백그라운드 세션의 임시 작업 공간, 일부 메모리 Markdown 파일 등이 해당합니다. 일반적인 Manual 및 acceptEdits 세션에서는 보호 경로에 쓰려고 할 때 승인을 요청하며, 자동 모드에서는 분류 모델에 판단을 맡깁니다. 설정 파일의 allow 규칙으로 이러한 쓰기를 미리 승인할 수는 없습니다. 보호 경로와 예외

Claude Code 자동 승인: 중단을 줄이는 더 안전한 네 가지 방법

작업이 중단되는 원인에 맞춰 제어 방식을 선택해야 합니다. 대부분의 개발자에게 먼저 필요한 것은 권한 우회보다 더 정밀한 승인 정책입니다.

일반적인 코딩 작업에는 자동 모드를 사용합니다

claude --permission-mode auto로 세션을 시작합니다. 제안된 동작을 검토하는 별도의 모델인 분류 모델이 통상적인 승인 여부를 판단합니다. 터미널의 기본값으로 계속 사용하려면 ~/.claude/settings.json에 "permissions": {"defaultMode": "auto"}를 병합합니다.

같은 값을 .claude/settings.json이나 .claude/settings.local.json에 넣어도 자동 모드가 활성화되지는 않습니다. 자동 모드 사용 가능 여부는 지원 모델과 조직 설정에도 좌우되며, 명시적인 ask 규칙은 여전히 승인을 요청합니다. 작업 중단을 줄여 주지만 안전을 보장하지는 않습니다. 기본 모드 설정, 자동 모드 사용 요건

이 검토 모델이 어떤 워크플로에 적합한지는 Claude Code 자동 모드 가이드에서 설명합니다.

반복 작업은 허용하고 특정 동작은 차단합니다

검토를 마친 명령은 permissions.allow에, 차단할 작업은 permissions.deny에 지정합니다. Claude Code는 deny, ask, allow 순서로 규칙을 평가합니다. 광범위한 allow 규칙도 일치하는 deny 규칙을 무효화할 수 없습니다. 권한 규칙

다음은 신뢰할 수 있는 저장소에서 제한적인 승인 규칙과 차단 훅을 함께 사용하는 예입니다. 기존 키를 유지하면서 .claude/settings.json에 병합합니다. 여기에 나열한 승인 규칙이 적용되도록 터미널 세션을 의도적으로 Manual 모드에서 시작합니다. 테스트 및 린트 명령을 승인하기 전에 프로젝트의 해당 스크립트가 실제로 무엇을 실행하는지 확인해야 합니다.

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

개인용 프로젝트 설정으로 덮어쓰려면 .claude/settings.local.json을 사용합니다. 직접 파일을 만들었다면 .gitignore에 추가합니다. /permissions를 열면 적용 중인 규칙과 각 규칙의 출처 파일을 확인할 수 있습니다. 설정의 적용 범위

이러한 패턴이 파일시스템이나 네트워크를 격리해 주지는 않습니다. 같은 동작을 다른 명령 표현으로 실행하면 Bash 패턴을 피할 수 있고, 임의의 스크립트는 파일 툴의 deny 규칙이 있어도 파일을 간접적으로 읽을 수 있습니다. 비밀 정보는 실행 환경 밖에 두고, 접근 자체가 불가능해야 하는 경우에는 샌드박스로 강제해야 합니다. Bash 규칙의 한계, 파일 규칙의 한계

변경 범위가 넓다면 먼저 계획 모드를 사용합니다

claude --permission-mode plan으로 시작하거나 프로젝트 설정에 "permissions": {"defaultMode": "plan"}을 지정합니다. Claude는 소스 수정이 승인되기 전에 코드를 살펴보고 작업을 제안합니다. 최상위 설정인 "useAutoModeDuringPlan": false는 계획 단계의 명령을 분류 모델이 승인하는 기능을 끕니다. 따라서 기본 제공 읽기 전용 명령 범위를 벗어나는 명령에는 사용자의 승인이 필요합니다. 계획 모드 설정

권한 우회를 사용할 수 있게 만드는 플래그 없이 새 계획 세션을 시작해야 합니다. 대화형 터미널 세션에서 권한 우회를 선택할 수 있는 상태라면, 계획 모드의 일반적인 수정 및 명령 차단이 강제되지 않습니다. 권한 우회를 즉시 활성화하지 않고 나중에 선택할 수 있게 하는 --allow-dangerously-skip-permissions를 지정한 경우도 여기에 포함됩니다. 계획 모드와 권한 우회 사용 가능 여부

특정 명령을 차단하려면 훅을 사용합니다

예제의 hooks.PreToolUse 핸들러는 matcher: "Bash", type: "command", if: "Bash(rm *)"를 사용합니다. 조건이 일치하면 셸 명령이 이유를 출력하고 종료 상태 2를 반환해 툴 호출을 차단합니다. 별도의 스크립트는 필요하지 않습니다. 이 셸 명령은 Anthropic이 문서화한 훅 필드와 차단용 종료 상태를 바탕으로 작성한 간단한 예제입니다. 훅 설정, 차단용 종료 코드

이 훅은 패턴에 일치하는 rm 호출을 차단할 뿐, 파일을 삭제하는 모든 방법을 막지는 않습니다. 팀 자체의 배포나 정리 명령을 검사하도록 검토를 마친 검증기로 대체할 수도 있습니다. 검사 범위는 동작을 이해하고 테스트할 수 있을 만큼 좁게 유지해야 합니다. 훅 설정과 디버깅은 Claude Code 훅 가이드에서 다룹니다.

Anthropic은 어떤 환경에서 권한 우회를 허용할까요?

Anthropic의 일반적인 설정 조합 표는 컨테이너, VM 또는 샌드박스 런타임을 요구하며, Linux와 macOS에서는 root가 아닌 사용자를 사용하도록 합니다. 권한 우회 설명에서는 호스트에 손상을 줄 수 없는 격리된 환경을 제시하고, 인터넷에 접근할 수 없는 환경을 명시합니다. 개발 컨테이너 가이드는 Claude에 필요한 서비스에 한해 외부 통신을 제한적으로 허용하는 연결 환경을 제공합니다. 제한 없는 네트워크 접근은 별도의 노출 위험으로 봐야 합니다. 필수 격리 요건, 개발 컨테이너의 네트워크 제한

Linux와 macOS에서 root로 또는 sudo를 통해 권한 우회를 실행하면 일반적으로 거부됩니다. 문서에는 인식된 샌드박스 내부에서 자동으로 적용되는 예외가 나와 있지만, 문서화된 개발 컨테이너 방식은 root가 아닌 계정을 사용합니다. root 관련 오류를 해결하려고 이 경계를 약화해서는 안 됩니다.

공식 예제로 개발 컨테이너를 빠르게 구성합니다

신뢰할 수 있는 저장소의 일회용 체크아웃을 사용합니다. Docker, VS Code, Dev Containers 확장 기능이 설치되어 있다면 Anthropic의 예제 프로젝트에서 시작합니다.

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. VS Code에서 Dev Containers: Reopen in Container를 실행합니다. 이 예제는 CLI, 영구 볼륨, 아웃바운드 방화벽을 함께 구성합니다. remoteUser가 root가 아닌 계정을 지정하는지 확인합니다.
2. 컨테이너 터미널에서 id -u를 실행하고 결과가 0이 아닌지 확인합니다. claude를 실행해 로그인한 뒤 해당 세션을 종료합니다.
3. 같은 컨테이너 터미널에서 claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissions를 실행합니다.
4. 자신의 프로젝트에 적용하려면 예제의 .devcontainer/ 디렉터리를 일회용 체크아웃에 복사하고, 툴체인에 맞게 Dockerfile을 조정합니다. 각 작업이 끝날 때마다 작업 공간의 diff를 검토합니다.

이 절차는 Anthropic의 예제 컨테이너 워크플로를 따릅니다. 이 예제는 동작을 보여 주는 구현이며, 지속적으로 유지보수되는 베이스 이미지는 아닙니다. 예제의 아웃바운드 제한을 유지하거나 동등한 네트워크 제어를 마련해야 합니다.

마운트된 작업 공간에는 컨테이너 안에서도 계속 쓸 수 있으며, 변경 사항은 호스트에도 반영됩니다. ~/.ssh, 클라우드 자격 증명 파일, 작업과 무관한 디렉터리는 마운트하지 않아야 합니다. 악성 프로젝트는 Claude 자격 증명을 포함해 컨테이너 내부에서 접근할 수 있는 모든 정보를 유출할 수 있습니다. 신뢰할 수 있는 저장소를 사용하고 작업을 모니터링해야 합니다. 개발 컨테이너의 한계

클라우드 세션은 권한 우회 기본값을 무시합니다

클라우드 세션은 설정 파일의 defaultMode: "bypassPermissions"와 defaultMode: "dontAsk"를 별도 안내 없이 무시합니다. 클라우드 모드 드롭다운에 표시된 모드로 시작합니다. 저장소에 체크인한 JSON 설정으로 클라우드 세션을 권한 우회 모드로 강제할 수는 없습니다. 클라우드 모드의 동작

로컬의 ~/.claude/settings.json은 Anthropic이 호스팅하는 클라우드 세션으로 전달되지 않습니다. 저장소 설정에도 별도의 제약이 있습니다. 여러 저장소에 걸친 세션에서는 각 저장소의 권한 규칙과 훅을 불러오지 않습니다. 터미널 설정이 그대로 적용된다고 가정하지 말고, 클라우드 환경에서 실제로 적용되는 정책을 확인해야 합니다. 클라우드 세션의 설정

작업에 맞게 권한 모드를 선택합니다

대개 가장 효과적인 개선은 기존 워크플로에서 반복되는 승인을 줄이는 것입니다. 제가 먼저 시도할 순서대로 실용적인 선택지를 정리했습니다.

CI 사례에서 Anthropic이 문서로 제시하는 출발점은 claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"입니다. 원래라면 승인 요청을 띄울 작업을 거부합니다. 일반적인 설정 조합

어떤 모드를 선택하든 Claude Code 모범 사례를 함께 참고하면 좋습니다. 권한은 실행을 통제하고, 검증은 그 결과를 남길 가치가 있는지 판단합니다.

팀에서 만들어 볼 만한 유용한 툴 두 가지

가장 유망한 아이디어는 권한 설정 검사기입니다. DataForSEO는 “claude code permissions”의 미국 월간 검색량을 720회로 추정합니다. 필요한 정보를 찾기 어렵다는 신호이지, 구매 의도가 입증됐다는 뜻은 아닙니다. 개발자 플랫폼 팀은 설정의 적용 범위를 설명하고, 무시되는 defaultMode 값을 표시하며, 동료를 온보딩하기 전에 광범위한 명령 규칙을 미리 검토할 수 있는 작은 검사기를 만들 수 있습니다. 첫 번째로 유용한 결과물은 수정 제안을 담은 보고서입니다. 다만 Claude Code의 설정 동작이 바뀔 때마다 검사기도 유지보수해야 합니다.

일회용 실행 환경을 시작하는 런처는 반복적인 무인 작업이 있는 팀에 도움이 될 수 있습니다. 같은 수요 조사에서 “claude code docker”의 미국 월간 검색량은 260회로 추정됩니다. MVP는 검토를 마친 컨테이너 템플릿, 허용된 마운트, root가 아닌 사용자로의 실행, 아웃바운드 정책을 검증한 뒤, 작업 결과의 diff와 로그를 유지보수 담당자에게 모아 줄 수 있습니다. 가치는 일관된 환경 구성에 있습니다. 다만 런처가 신뢰할 수 없는 저장소 코드를 안전하게 만들 수는 없으며, Docker가 있다는 이유만으로 격리를 보장할 수도 없습니다.

둘 다 실제 사용자와 함께 검증해 볼 만한 내부 툴 아이디어입니다. 어느 쪽도 개발자 컴퓨터의 기본값을 권한 우회로 바꿀 필요는 없습니다.

다가오는 월요일에는 반복되는 워크플로 하나를 골라 실제로 실행되는 명령을 검토하고, 작업을 끝내는 데 필요한 최소한의 승인 정책을 설정해 봅니다. 그 정책을 넘어서는 무인 실행이 필요한 경우에만 일회용 컨테이너로 옮깁니다.

팀에 이런 워크플로를 구축하고 유지보수할 도움이 필요하다면 AI 프로덕션 시스템에서 지원받을 수 있습니다.