Claude Code --dangerously-skip-permissions 사용법과 승인 생략의 범위

Claude Code에서 --dangerously-skip-permissions는 일반적인 도구 승인 요청을 생략하는 bypassPermissions 모드를 선택하는 실행 옵션입니다. claude --permission-mode bypassPermissions와 같은 모드를 선택합니다. 로그인, 운영체제 권한, 조직 정책까지 건너뛰는 옵션은 아닙니다. 명시적인 ask 규칙이나 반드시 사용자 응답이 필요한 도구 등은 여전히 실행을 멈출 수 있습니다. 이 글의 모드 설명은 2026년 10월 7일 확인한 공식 문서를 기준으로 합니다.

이미 실행 범위를 제한한 일회용 환경에서 이 모드를 선택하려면 다음 명령을 사용합니다. 설치와 인증이 완료되어 있어야 하며, 실행 프로세스가 접근할 수 있는 파일·자격 증명·네트워크의 범위를 먼저 정해야 합니다.

claude --dangerously-skip-permissions

파일 편집 때마다 확인하는 것이 불편한 정도라면 acceptEdits가 더 알맞습니다. 사람이 없는 작업에서 승인 요청 때문에 멈추지 않게 하되, 승인되지 않은 행동은 거절하고 싶다면 dontAsk를 사용합니다. 아래에서 정확한 실행 방법과 각 선택의 차이를 확인할 수 있습니다.

실행 옵션 세 가지: 즉시 선택과 사용 허용은 다릅니다

다음 두 명령은 모두 Bypass 모드로 시작합니다. 두 명령을 함께 지정할 필요는 없습니다.

claude --dangerously-skip-permissions

claude --permission-mode bypassPermissions

반면 다음 명령은 Bypass를 선택할 수 있게만 합니다. 시작할 때 바로 Bypass로 바꾸지는 않으며, 실제 시작 모드는 적용되는 설정과 기본값에 따라 정해집니다.

claude --allow-dangerously-skip-permissions

플래그를 넣었는데 계속 승인을 묻는다면 이 차이부터 확인하세요. 명령 이름의 --allow- 유무는 의미가 다릅니다. --dang처럼 줄여 쓴 검색어도 문서화된 실행 옵션으로 간주하면 안 됩니다. 정확한 철자는 CLI 옵션 문서에서 확인할 수 있습니다.

특히 대화형 터미널에서 Bypass를 사용할 수 있게 해 두면 Plan의 강제 편집·명령 차단이 적용되지 않습니다. 계획을 세우라는 지시는 남지만, --permission-mode plan --allow-dangerously-skip-permissions 조합을 읽기 전용 실행법으로 안내할 수는 없습니다. -p 실행, SDK, VS Code 채팅에서는 Plan의 강제 차단이 유지됩니다. 계획만 검토하려면 터미널에서 Bypass 허용 플래그를 함께 넣지 않는 편이 목적에 맞습니다. 해당 모드와 터미널 예외를 함께 확인하세요.

처음 실행할 때 확인할 것

설치된 클라이언트의 버전과 지원 옵션을 확인하는 문서상 명령은 다음과 같습니다.

claude --version
claude --help

대화형 세션에서는 /permissions로 권한 규칙을 확인하고, 현재 모드 표시도 함께 확인합니다. CLI에서 처음 Bypass에 진입할 때의 경고 동의와 모드 선택은 별개입니다. 동의 기록이 있다고 해서 다음 세션이 자동으로 Bypass가 되는 것은 아닙니다. -p 실행에는 이 경고 대화상자가 없고, --bg 시작은 사전 동의가 필요합니다. 공식 시작 조건에 따른 설명이며, 이 글에서는 실제 Bypass 세션을 실행하지 않았습니다.

승인 요청만 줄이고 싶다면 어떤 모드를 쓰나요?

모드 이름을 권한이 점점 커지는 순서로 외우기보다, 무엇을 자동으로 처리하고 무엇을 거절할지 정하는 편이 정확합니다. dontAsk는 Bypass보다 조금 덜 묻는 모드가 아니라, 승인이 필요한 호출을 거절하는 모드입니다.

위 동작은 현재 권한 모드 문서를 기준으로 합니다. UI의 Manual은 설정에서 default에 해당합니다. manual 별칭은 버전 2.1.200 이상에 문서화되어 있으므로, 설정 예제에는 호환되는 default를 쓰는 편이 명확합니다.

편집 승인을 줄이는 실행 명령은 다음과 같습니다.

claude --permission-mode acceptEdits

이 모드는 Edit·Write 도구에만 적용되는 것이 아닙니다. 허용된 작업 범위 안에서 흔히 쓰는 디렉터리 생성이나 파일 이동 같은 셸 파일 작업도 자동 승인할 수 있습니다. 작업 디렉터리 밖의 접근, 심볼릭 링크, 보호 경로, 중요한 삭제에는 별도 조건이 있으므로 “파일 수정은 전부 허용된다”로 이해하면 안 됩니다.

Auto 모드를 쓰고 싶다면 다음과 같이 명시적으로 선택합니다.

claude --permission-mode auto

2.1.283 이상에서는 대화형 터미널과 VS Code의 내장 시작 기본값이 여러 플랜과 제공자에서 Auto로 바뀌었지만, 지원 모델과 조직의 disableAutoMode 정책 등 가용성 조건은 여전히 적용됩니다. “Pro나 Max면 쓸 수 없다”는 오래된 구분도 현재의 일반 규칙으로 사용할 수 없습니다. -p·SDK에서는 기능 플래그를 가져오는 세션이 보통 Manual로 시작하고, 가져오지 않는 세션은 2.1.285 이상에서 Auto가 기본값입니다. HIPAA 적용 대상 조직에는 별도 Manual 기본값이 있습니다. 실제 시작 모드는 명시한 옵션과 적용 설정까지 함께 봐야 합니다. 버전별 기본값과 가용성을 확인하세요.

Auto가 반복해서 호출을 막아도 전부 승인되는 모드로 바뀌는 것은 아닙니다. 문서의 연속 3회 또는 누적 20회 차단 기준에서는 정해진 대체 동작을 사용하며, 승인 도구가 없는 -p 실행은 호출을 거절하고 계속할 수 있습니다. 실행이 끝났다는 사실과 요청한 작업을 완료했다는 사실을 구분해야 합니다.

반복 작업용 설정: 편집과 지정한 명령만 미리 승인하기

같은 프로젝트에서 파일 수정과 정해진 검사만 반복한다면, Bypass 대신 acceptEdits와 구체적인 허용 규칙을 조합할 수 있습니다. 아래는 프로젝트의 .claude/settings.json에 넣는 설정 예시입니다. 실제 프로젝트에 npm run lint와 npm test가 있어야 하며, 그 스크립트가 실행하는 내용도 먼저 확인해야 합니다.

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

의도는 편집과 두 검사 명령의 승인 횟수를 줄이고, 패턴에 맞는 push는 확인하며, 해당 경로의 Read 호출은 거절하는 것입니다. 일반 권한 규칙의 평가 순서는 deny → ask → allow입니다. 다른 설정 범위에 거절 규칙이 있으면 이 예제의 allow만으로 풀리지 않습니다. 경로 표기에서 ./는 현재 작업 디렉터리 기준이고, /는 설정 파일 기준, //는 절대 경로, ~/는 홈 디렉터리 기준이라는 차이도 있습니다. 규칙 문법과 경로 기준을 적용 위치와 함께 확인하세요.

이 설정을 비밀 파일의 완전한 접근 차단으로 사용하면 안 됩니다. Read 규칙과 Bash 문자열 규칙은 모든 외부 프로그램의 파일 접근을 통제하지 않습니다. 예를 들어 허용한 npm 스크립트가 다른 프로그램을 실행하면, 그 프로그램이 읽는 파일까지 단순 명령 패턴으로 검증할 수 없습니다. 비밀 파일을 프로세스에 제공하지 않거나, 별도의 운영체제 격리로 접근을 막아야 합니다.

승인 대기 없이 제한된 보고서만 받고 싶다면

다음은 설치·인증이 완료된 CLI에서 저장소 문서를 읽어 보고서를 출력하는 문서 기반 예시입니다. 기본 제공 도구를 읽기·검색 도구로 제한하고 MCP 도구는 별도로 제외합니다.

claude --permission-mode dontAsk --tools "Read,Grep,Glob" --disallowedTools "mcp__*" -p "저장소의 README와 문서에서 테스트 실행 방법을 찾아 한국어로 설명하세요. 파일은 수정하지 마세요."

확인이 필요한 호출이 생기면 dontAsk가 거절하므로, 필요한 문서를 읽지 못했거나 도구가 거절된 결과도 확인해야 합니다. --tools는 기본 제공 도구의 목록을 제한하고 MCP에는 적용되지 않습니다. --allowedTools는 도구를 사전 승인하는 옵션이며, 다른 도구를 모두 제거하는 옵션이 아닙니다. CLI 도구 선택 옵션의 차이입니다.

이 명령도 전체 프로세스의 격리 설정은 아닙니다. 로드되는 hook과 외부 보조 프로그램 등은 별도로 봐야 합니다. 또한 모드와 도구 구성이 달라지면 수행할 수 있는 작업도 줄어듭니다. 위 예제는 변경 작업을 자동으로 끝내는 명령이 아니라 문서 보고서를 받는 용도입니다. JSON 문법과 예제 구성의 검토는 실제 클라이언트가 해당 설정을 받아들이거나 접근 차단이 성공했다는 실험을 대신하지 않습니다.

Bypass인데도 계속 묻거나 실행을 거절하는 이유

모드가 실제로 Bypass라면, 남은 확인이 어떤 종류인지 구분해야 합니다. 일반적인 파일 쓰기 승인과 별도로 강제되는 사용자 응답은 같은 절차가 아닙니다.

현재 Bypass는 보호 경로에 대한 일반 쓰기도 보통 허용합니다. 따라서 “보호 경로 쓰기는 항상 다시 승인받는다”는 과거 설명으로 동작을 판단하면 안 됩니다. 반면 중요한 삭제 검사는 별개입니다. 2.1.281 이상에서 Auto·Bypass의 해당 터미널 삭제 확인에는 2분 제한이 있고, 반복해서 응답하지 않으면 거절됩니다. 비터미널 Auto에서는 해당 삭제가 거절됩니다. PowerShell의 시스템 경로나 와일드카드 삭제에는 모든 모드에 적용되는 별도 거절도 있습니다. 이를 근거로 모든 삭제가 차단된다거나 모든 호출에서 확인이 사라진다고 보장할 수는 없습니다. 현재의 예외와 시작 제한이 판단 기준입니다.

Linux·macOS의 root 시작 검사에는 인식된 샌드박스 환경의 예외가 문서화되어 있지만, 일반 시스템에서 root 제한을 피하는 방법으로 사용해서는 안 됩니다. 공식 Dev Container 안내도 Bypass에는 비 root 사용자를 권합니다.

deny와 hook이 있으면 Bypass도 항상 안전한가요?

일반 권한 규칙에서는 deny가 Bypass에서도 우선하며, PreToolUse hook의 차단도 유지될 수 있습니다. 다만 프로세스 안에 설치된 mod의 tool.check는 ask·hook·분류기 판단과 일부 deny 정책을 덮어쓸 수 있습니다. 관리형 hook과 Team·Enterprise 또는 관리형 deny 정책에는 별도 보호 조건과 정책 예외가 있습니다. 공식 권한 문서의 mod 예외를 고려하지 않고 “deny만 있으면 어떤 확장에서도 차단된다”고 말할 수는 없습니다.

명령 문자열을 검사하는 정규식 hook도 전체 셸이나 실행된 모든 프로그램을 이해하는 보안 경계는 아닙니다. 외부 프로그램, 중첩 실행, 다른 인터프리터를 통해 생기는 접근까지 막으려면 프로세스 바깥의 통제가 필요합니다.

CLI에서는 되는데 VS Code나 웹에서는 왜 안 보이나요?

터미널의 실행 옵션이 모든 화면에 같은 형태로 나타나지는 않습니다. 현재 웹 클라우드 세션은 Bypass를 선택할 수 없습니다. CLI 오류로 볼 상황이 아닙니다.

표는 공식 문서의 CLI·VS Code·Desktop·Web/mobile·JetBrains별 설명을 기준으로 합니다. 프로젝트 설정에 "defaultMode": "bypassPermissions"를 적어 넣는 방법도 기본 활성화 수단이 아닙니다. 프로젝트의 Auto·Bypass 기본값은 적용되지 않으며, Bypass를 적은 경우 Manual로 시작합니다. 사용자 설정, 명시적인 --settings, 관리형 설정과 혼동하지 마세요.

종료한 세션을 이어서 열면 Bypass가 유지되나요?

실행 중인 백그라운드 세션에 다시 연결하는 것과, 저장된 대화 기록을 새 터미널 세션으로 복원하는 것은 다릅니다. 실행 중인 백그라운드 세션은 모드를 유지합니다. 터미널에서 정확한 세션 ID·이름이나 --continue로 기록을 복원할 때는 일반적으로 저장된 모드를 복구하지만, Bypass와 Plan은 새 세션의 시작 모드로 돌아갑니다. Bypass는 다시 명시적으로 활성화해야 합니다.

시작할 때 세션 선택기를 여는 방식은 새 세션의 모드를 사용하고, 진행 중인 세션 안에서 /resume하는 방식은 현재 모드를 유지합니다. -p 재개는 새 -p 실행의 기본값을 사용하며, Plan 복원에는 버전·승인 도구·다른 옵션 여부에 따른 별도 조건이 있습니다. 과거에 Bypass로 실행했다는 이유만으로 재개한 세션도 같다고 판단하지 말고, 시작 직후 실제 모드를 확인하세요. 세션 재개 시 권한 모드에 정리된 차이입니다.

무인 실행 전에 확인할 격리 범위

무인 실행에 필요한 것은 Bypass 옵션 하나가 아니라, 잘못된 호출이 닿을 수 있는 범위가 정해진 환경입니다. Git 브랜치와 worktree는 코드 변경을 분리할 뿐, 홈 디렉터리·운영 자격 증명·네트워크 접근을 차단하지 않습니다. 컨테이너도 호스트 폴더를 쓰기 가능하게 마운트하면 그 변경이 호스트에 그대로 반영됩니다.

먼저 다음 네 가지를 준비합니다.

1. 일회용 컨테이너나 VM 등에서 프로세스 전체가 접근할 파일 범위를 정합니다. 실제 운영 파일과 불필요한 호스트 폴더는 제공하지 않습니다.
2. 상속되는 환경 변수와 연결된 자격 증명의 범위를 관리합니다. 호스트의 SSH·클라우드 자격 증명이나 Docker 소켓을 그대로 연결하지 않습니다. 값을 화면에 출력하는 점검보다 제공하지 않는 설계가 먼저입니다.
3. 사용할 모델 제공자와 인증에 필요한 네트워크 목적지를 확인하고, 업무에 필요 없는 목적지는 제한합니다. 허용된 목적지로도 데이터가 나갈 수 있으므로 네트워크 목록만으로 유출 방지를 보장하지 않습니다.
4. 돌려받을 결과를 diff와 필요한 검사로 검토합니다. Git으로 추적되지 않는 파일, 외부 API 호출, 계정 변경은 커밋 복구만으로 되돌릴 수 없으므로 작업 대상에서 분리합니다.

전체 프로세스 격리 안내는 내장 명령 샌드박스와 외부 컨테이너·VM의 범위를 구분합니다. 내장 샌드박스는 Bash·PowerShell·Monitor와 그 자식 프로세스를 감싸며, 파일·웹 도구, MCP, hook, LSP, mod, 화면 제어 등은 포함하지 않습니다. 기본값도 꺼짐입니다. “샌드박스를 켰다”는 말만으로 모든 도구가 격리되었다고 판단할 수 없습니다.

내장 샌드박스에서 놓치기 쉬운 설정

위 설정은 공식 샌드박스 문서의 현재 범위를 전제로 합니다. 샌드박스의 명령 자동 승인은 auto 권한 모드의 분류기 검토와도 다른 기능입니다. 설정 파일이 있다는 사실, 프로세스가 시작된 사실, 검사 명령이 성공한 사실만으로 의도한 차단 정책의 적용을 증명할 수는 없습니다.

공식 Dev Container 안내를 사용한다면 다음 차이를 확인하세요. Claude Code Feature를 추가하는 것만으로 기본 거절 방화벽이 설치되지는 않습니다. :1.0 태그는 Feature 설치 스크립트 버전을 고정하며, Claude Code 릴리스 자체를 고정하는 것은 아닙니다. 비 root remoteUser, 설치할 CLI 버전, 업데이트 방식, 실제 마운트와 네트워크 정책을 각각 정해야 합니다. 공식 참조의 devcontainer.json·Dockerfile·init-firewall.sh는 작업 예시이며 지속 관리되는 기본 이미지라는 뜻은 아닙니다.

또한 컨테이너를 재빌드하면 홈 디렉터리의 상태가 사라질 수 있고, 설정 볼륨을 영속화하면 인증 정보와 대화 기록도 남을 수 있습니다. 어느 쪽이든 저장 범위를 확인해야 합니다. 인터넷을 끊으면 로컬 캐시만으로 Claude가 계속 추론한다는 보장도 없습니다. 격리된 실행에서도 요청 내용과 읽은 파일은 설정된 모델 제공자에게 전송될 수 있으므로, 모델 통신이 필요한 네트워크와 파일 접근을 함께 설계해야 합니다.

자주 묻는 질문

권한을 건너뛰면 로그인도 생략되나요?

아니요. --dangerously-skip-permissions는 도구 승인 모드를 선택합니다. 인증, 구독·사용량 제한, 운영체제 권한을 바꾸지는 않습니다. sudo를 대신하는 기능도 아닙니다. 옵션과 모드의 범위를 구분하세요.

묻지 않고 실행하려면 dontAsk와 Bypass 중 무엇을 선택하나요?

승인되지 않은 행동을 거절하고 이미 허용된 작업만 실행하려면 dontAsk입니다. 일반 도구 호출을 승인 요청 없이 허용하려면 Bypass입니다. dontAsk도 필요한 호출이 거절될 수 있으므로 결과에서 작업 완료 여부를 확인해야 합니다. 모드별 동작에 따른 차이입니다.

Bypass를 기본값으로 적었는데 왜 적용되지 않나요?

프로젝트의 permissions.defaultMode에 적은 Bypass는 적용되지 않으며 Manual로 시작합니다. VS Code 채팅은 프로젝트 설정을 시작 모드로 읽지 않습니다. CLI의 명시적 실행 옵션과 사용자·관리형 설정, IDE의 별도 설정을 구분해 확인하세요. 환경별 시작 모드가 기준입니다.

Docker 안이면 prompt injection도 막을 수 있나요?

Docker 자체가 프롬프트 인젝션을 막지는 않습니다. 외부 문서나 코드가 모델의 행동에 영향을 주는 문제와, 그 행동이 접근할 수 있는 파일·네트워크 범위는 별개입니다. 쓰기 가능한 호스트 마운트, 자격 증명, Docker 소켓, 허용된 네트워크가 있으면 컨테이너 밖에 영향을 줄 수 있습니다. 외부 격리의 범위와 한계를 확인해야 합니다.

CI에서 -p를 쓰려면 반드시 Bypass여야 하나요?

아니요. 필요한 도구와 허용 규칙을 정하고 dontAsk로 실행하는 선택도 가능합니다. 다만 승인 요청이 필요한 호출은 거절되므로 실행 성공 여부만 보지 말고 원하는 결과를 얻었는지 확인해야 합니다. 운영 배포·패키지 발행·계정 변경 권한이 있는 CI에서는 권한 범위를 별도로 줄이고 승인 단계를 마련하는 것이 우선입니다. CLI 옵션과 dontAsk 동작을 함께 적용하세요.