Claude Code --dangerously-skip-permissions 는 단순히 승인 창을 줄이는 편의 옵션이 아닙니다. 현재 권한 모드에서는 --permission-mode bypassPermissions 와 같은 계약으로 보아야 하며, Claude Code가 일반적인 권한 확인 단계를 거치지 않고 계속 실행된다는 뜻입니다. 파일 쓰기, 셸 명령, 네트워크 호출, 도구 실행처럼 부작용이 있는 작업에서 사람이 멈춰 확인할 기회가 줄어듭니다. 2026년 5월 7일 기준 실무 규칙은 분명합니다. 일반 개발 노트북, 실제 비밀값이 있는 셸, 배포나 삭제 권한이 있는 환경에서는 기본 실행 방식으로 쓰면 안 됩니다.
먼저 어떤 불편을 해결하려는지 나누어야 합니다. 예측 가능한 파일 편집 승인이 귀찮다면 acceptEdits 를 먼저 검토합니다. 길고 반복적인 저장소 작업이고 버전, 플랜, 모델, provider, 사용 표면 조건이 맞는다면 Auto mode를 확인합니다. 처음 보는 저장소, 영향 범위가 넓은 변경, 장애 원인 조사라면 기본 모드나 plan 이 먼저입니다. 완전한 bypass는 실패해도 임시 작업 공간만 망가지는 격리 상태에서만 논의할 수 있습니다.
빠른 판단:
- 낯선 코드, 불명확한 영향 범위, 원인 조사:
default또는plan. - 반복 편집 승인만 줄이고 싶음:
acceptEdits. - 낮은 위험의 긴 저장소 작업: 조건이 맞으면 Auto mode.
- secret, prod, DB, cloud admin, deploy, billing 접근 가능: bypass 금지.
- 파일, 네트워크, 자격 증명, 명령 범위, 되돌리기가 모두 격리됨: 그때만
bypassPermissions검토.
빠른 결론: 이 플래그가 실제로 없애는 것
Claude Code 권한 모드 문서에서 --dangerously-skip-permissions 는 --permission-mode bypassPermissions 와 같은 의미로 다뤄집니다. 모델이 더 똑똑해지는 기능도 아니고, 작업 품질을 보장하는 기능도 아닙니다. 정상적으로는 사용자가 확인하던 제어 지점을 통과하게 만드는 설정입니다.
권한 프롬프트는 번거롭지만, 가장 싼 검토 지점이기도 합니다. 어떤 파일을 쓰는지, 어떤 명령을 실행하는지, 네트워크로 나가는지, 작업이 더 위험한 영역으로 번졌는지 확인할 수 있습니다. 문서 수정이 설치 스크립트 실행으로 바뀌거나, 테스트 실행이 대량 생성물 수정으로 바뀌거나, 설정 점검이 .env 읽기로 흘러갈 때 그 지점에서 멈출 수 있습니다.
명령보다 먼저 선택해야 할 것은 모드입니다.
| 상황 | 먼저 쓸 모드 | 이유 |
|---|---|---|
| 새 저장소, 낯선 버그, 영향 범위 불명확 | default 또는 plan | 실행 전에 가시성이 필요함 |
| 일반 편집 승인 피로 | acceptEdits | 편집은 줄이고 명령 판단은 남김 |
| 반복 가능한 낮은 위험 작업 | Auto mode | 완전 bypass보다 좁은 중간층 |
| 일회용 격리 환경, 실제 권한 없음 | bypassPermissions | 안전 경계는 플래그가 아니라 환경 |
| 운영, 비밀값, DB, cloud, billing, deploy | 쓰지 않음 | 실패 반경이 너무 큼 |
이 표를 먼저 보는 이유는 명령이 어렵지 않기 때문입니다. 어려운 것은 잘못된 동작이 어디까지 닿을 수 있는지 줄이는 일입니다.
권한 모드 사다리: 필요한 단계까지만 올리기
Claude Code 권한은 승인 창을 켜고 끄는 스위치가 아니라 위험 사다리입니다. 기본 모드는 모르는 작업에 맞습니다. 부작용이 있는 행동 전에 멈추기 때문에 파일, 명령, 대상, 의도를 확인할 수 있습니다. 처음 보는 코드, 의존성, 설정, 인증, 릴리스 주변 작업에서는 이 멈춤이 속도보다 값어치 있습니다.
plan 은 명령 자체보다 접근 방식이 위험할 때 필요합니다. 권한 구조를 바꾸거나, 데이터 흐름을 옮기거나, 빌드 체계를 손보거나, 결제 로직과 연결된 작업을 할 때는 먼저 계획을 고정해야 합니다. 잘못된 방향을 초기에 막는 것이 나중에 개별 명령을 멈추는 것보다 싸게 먹힙니다.
acceptEdits 는 많은 승인 피로에 대한 현실적인 답입니다. Claude Code가 예상 가능한 파일 편집을 하도록 두면서도 셸, 네트워크, 외부 도구 판단은 남길 수 있습니다. 문서, 테스트, 타입 수정, 작은 리팩터링에서는 완전 bypass 없이도 충분히 빨라집니다.
Auto mode는 중간층입니다. 사용자가 많은 프롬프트를 승인하고 있었지만 완전 bypass는 너무 넓었기 때문에 만들어진 선택지입니다. 다만 가용성은 Claude Code 버전, 계정 플랜, 모델, provider, 사용 표면에 따라 달라집니다. 오래된 안내의 조건을 그대로 복사하지 말고 현재 환경에서 확인해야 합니다.
dontAsk 와 bypassPermissions 는 환경이 안전을 책임져야 하는 단계입니다. 핵심은 "Claude를 믿는다"가 아니라 "이 환경에는 망가질 실제 권한이 없다"입니다. 홈 디렉터리, SSH key, cloud CLI, 내부 네트워크, 브라우저 로그인, 운영 secret이 보이면 이 단계로 올라가면 안 됩니다.
금지선: 이런 작업에는 bypass를 쓰지 않기
공유 시스템을 망가뜨리거나, secret을 유출하거나, 되돌리기 어려운 상태를 만들거나, 돈과 권한을 바꿀 수 있는 작업에는 --dangerously-skip-permissions 가 맞지 않습니다. 이는 Claude Code만의 문제가 아니라, 셸과 파일 시스템과 네트워크를 가진 모든 자동화 에이전트의 공통 위험입니다.
금지할 범위:
- production deploy, rollback, release promotion, service restart.
- database migration, destructive query, bulk data change.
- Terraform, IAM, cloud resource, repository permission, billing.
- secret rotation, token search,
.envcleanup, credential debugging. - downloaded code execution, unknown install script,
curl | bash, unreviewed binary. - force push, protected branch 직접 push, 대량 삭제.
- 실제 운영 자격 증명, cloud CLI, SSH, 관리자 브라우저 세션이 있는 환경.
Auto mode의 차단 범주도 같은 원리입니다. 다운로드 코드 실행, 운영 배포, migration, sensitive data exfiltration, cloud storage mass deletion, IAM, repo permission, shared infrastructure, irreversible destruction, force push, direct push to main은 확인을 줄일 대상이 아닙니다.
팀에서는 금지 조건을 alias나 wrapper에도 넣는 편이 낫습니다. main branch, 더러운 diff, production token, deploy script, migration script, cloud profile이 보이면 시작 자체를 막습니다. 이렇게 해도 bypass가 안전해지는 것은 아니지만, 시작하면 안 되는 위치를 빠르게 실패시킬 수 있습니다.
bypass 전 격리 체크리스트
Claude Code sandboxing 문서의 핵심은 파일 시스템과 네트워크를 함께 좁히는 것입니다. 새 브랜치는 sandbox가 아닙니다. Docker도 host mount, 넓은 네트워크, 실제 credential, cloud CLI, 운영 endpoint가 있으면 sandbox가 아닙니다.
최소 확인:
| 경계 | 최소 조건 | 확인할 것 |
|---|---|---|
| 파일 시스템 | 일회용 worktree, 좁은 repo, 깨끗한 diff | pwd, git status, ignored/generated paths |
| 네트워크 | offline 또는 제한된 outbound | prod, staging, internal API, object storage 차단 |
| 비밀값 | production token, live .env 없음 | env vars, credential files, keychain, shell history |
| 명령 범위 | deploy, billing, IAM, migration, destructive script 없음 | package scripts, Makefile, CI helper, cloud CLI |
| 되돌리기 | 모든 변경이 diff와 rollback 가능 | checkpoint commit, tests, logs, rollback plan |
| 중지 규칙 | 하나라도 증명 안 됨 | default, plan, acceptEdits, Auto로 회귀 |
준비 예시는 단순할 수 있습니다.
bashgit status --short git worktree add ../tmp-claude-bypass-work -b claude-bypass-test cd ../tmp-claude-bypass-work
속도보다 권한 제거가 먼저입니다.
bashenv | grep -E 'TOKEN|KEY|SECRET|AWS|GCP|AZURE|ANTHROPIC|OPENAI' ls -la | grep -E '\.env|credentials|secrets' git diff --stat
이 점검에서 실제 credential이나 넓은 workspace가 보이면 멈춰야 합니다. "조심해서 실행"이 아니라 환경을 더 작게 만드는 것이 답입니다. 완전 bypass의 전제는 모델 신뢰가 아니라 실수 비용이 낮은 구조입니다.
사용 표면: CLI, IDE, Remote Control, cloud, CI는 다르다
모든 Claude Code 표면이 같은 권한 제어를 드러내지는 않습니다. local CLI는 시작 플래그, 권한 모드, /permissions 확인이 가장 직접적입니다. IDE, Remote Control, cloud session, non-interactive run은 각각 별도 제약을 가집니다.
| 표면 | 기대할 것 | bypass 판단 |
|---|---|---|
| Local CLI | 문서화된 mode와 flag가 가장 잘 보임 | 그래도 가장 낮은 위험부터 선택 |
| VS Code / IDE | advanced mode가 설정과 editor flow에 좌우됨 | 범위가 좁은 편집과 diff review 중심 |
| Remote Control | 원격 승인, 거절, 방향 수정 | unattended bypass가 아님 |
| cloud session | 현재 docs상 Ask permissions, Auto, Bypass를 드러내지 않음 | local CLI 문제로 오해하지 않기 |
| CI | secret, deploy, publish와 연결되기 쉬움 | narrow script, dry run, approval 우선 |
| secret/admin | 권한 자체가 위험 등급을 바꿈 | no bypass |
Remote Control은 다른 장치에서 감독하고 승인하는 표면입니다. Auto mode는 일부 긴 낮은 위험 작업의 승인 피로를 줄이는 중간층입니다. 완전 bypass는 둘 중 어느 것도 아닙니다. 이 차이를 섞으면 "감독되고 있다"와 "확인이 없다"를 같은 것으로 착각하게 됩니다.
안전 판단 뒤의 명령
경계 판단이 끝난 뒤에야 명령을 적습니다.
bashclaude --permission-mode bypassPermissions
많이 보이는 alias는 다음입니다.
bashclaude --dangerously-skip-permissions
새로운 runbook에는 첫 번째 형태가 현재 권한 모드 이름과 맞습니다. 기존 script, issue, 동료의 재현 명령에는 두 번째 형태가 남아 있을 수 있습니다. 둘이 같은 안전 계약이라는 점을 명확히 적어 두어야 합니다.
시작 전 점검:
bashclaude --version claude --help
세션 안에서는 다음을 확인합니다.
text/permissions
작업 중 모드를 바꿨다면 commit message나 작업 메모에 남깁니다. reviewer가 diff만 보고 언제부터 확인 없이 실행됐는지 모르는 상태가 가장 위험합니다.
버전 사실도 날짜를 붙여야 합니다. 2026년 5월 7일 확인한 docs에서는 v2.1.126 이후 protected paths 관련 동작과 root/home deletion circuit breaker를 언급합니다. 이것은 영구 보장이 아닙니다. 더 안정적인 답은 처음부터 위험한 파일 범위를 세션에 주지 않는 것입니다.
계속 묻거나, 모드가 보이지 않을 때
먼저 사용 표면을 확인합니다. cloud session, Remote Control, IDE, local CLI는 같지 않습니다. 한 표면에서 option이 보이지 않는다고 전체 permission mode 계약이 바뀐 것은 아닙니다.
다음은 Auto mode와 bypass의 혼동입니다. Auto는 더 안전한 적은 확인 경로지만 버전, 플랜, 모델, provider, 표면 조건이 있습니다. 나타나지 않는다면 eligibility 문제일 수 있습니다.
셋째, circuit breaker를 일반 확인과 혼동하지 마십시오. bypass 중에도 root나 home directory 삭제에서 멈추는 경우가 있어도, 그것은 안전하다는 뜻이 아닙니다. 마지막 비상 경계가 남아 있다는 뜻에 가깝습니다.
넷째, 조직 설정을 봅니다. managed settings, allowlist, denylist, dev container, audit policy가 있으면 로컬 동작이 공개 예시보다 좁을 수 있습니다. 이때 더 높은 권한으로 우회하지 말고 정책에 맞는 작업 방식을 정해야 합니다.
마지막으로 Claude Code가 계속 위험한 행동을 시도한다면 권한을 올리지 말고 낮추십시오. plan 으로 범위를 다시 잡고, 편집 피로는 acceptEdits 로 처리하고, 조건이 맞는 작업은 Auto mode를 씁니다.
자주 묻는 질문
--dangerously-skip-permissions 와 bypassPermissions 는 같은가요?
예. 현재 권한 모드 문서에서는 같은 계약으로 다룹니다. 팀 문서에 두 이름의 대응 관계를 적어 두면 숨은 모드처럼 오해하지 않습니다.
Docker에서 실행하면 안전한가요?
정말 격리된 경우에만 그렇습니다. host mount, 넓은 네트워크, real credentials, production CLI가 있으면 Docker도 위험한 일반 환경과 크게 다르지 않습니다.
승인 창이 귀찮을 뿐이면 무엇을 쓰나요?
먼저 acceptEdits 입니다. 편집 승인은 줄이고 명령과 네트워크 판단은 남길 수 있습니다. 조건이 맞으면 Auto mode도 후보입니다.
prompt injection을 막아 주나요?
아니요. bypassPermissions 는 prompt injection이나 unintended actions에 대한 보호를 제공하지 않습니다. 외부 파일이나 의존성이 세션에 영향을 줄 수 있다면 검토 공백이 더 커집니다.
CI에서 써도 되나요?
기본값으로 두지 마십시오. CI는 secrets, deploy permissions, package publishing, shared infrastructure와 연결되기 쉽습니다. 필요하면 narrow script, dry run, approval gate, 권한 없는 sandbox를 설계해야 합니다.
가장 안전한 실무 규칙은?
실제 병목을 해결하는 가장 낮은 권한을 씁니다. 편집 확인 피로는 acceptEdits, 조건이 맞는 긴 작업은 Auto mode, 완전 bypass는 운영, secret, billing, shared system에 닿지 않는 일회용 격리 환경에만 둡니다.