Claude Code에서 매번 승인하지 않도록 설정하는 3가지 방법

Claude Code는 파일 수정, 셸 명령 실행, 네트워크 요청처럼 작업 환경에 영향을 주는 행동을 하기 전에 권한을 묻는다. 이 승인 단계는 안전장치지만, 반복적인 개발 작업에서는 흐름을 끊기도 한다.

2026년 5월 29일 기준 공식 문서를 다시 확인해 보면, 실무에서 먼저 고려할 선택지는 세 가지다. 무조건 모든 승인을 끄기보다, 작업 위험도에 맞게 권한 범위를 좁혀 두는 편이 낫다.

빠른 선택 기준

방법적합한 상황주의점
acceptEdits파일 수정은 자동으로 맡기고, 민감한 명령은 계속 확인하고 싶을 때작업 디렉터리 밖, 보호 경로, 대부분의 Bash 명령은 여전히 승인이 필요하다.
permissions.allow반복해서 쓰는 명령만 승인 없이 실행하고 싶을 때Bash(*)처럼 넓은 규칙은 피하고, 필요한 명령만 정확히 허용해야 한다.
auto긴 작업에서 승인 피로를 줄이고 싶을 때연구 프리뷰이며 계정, 모델, 프로바이더 조건을 만족해야 한다.

1. 일반 개발은 acceptEdits부터 시작하기

가장 무난한 선택지는 acceptEdits 모드다. 이 모드는 Claude가 작업 디렉터리 안의 파일을 만들거나 수정하는 일을 승인 없이 진행하게 해 준다. mkdir, touch, mv, cp, sed 같은 일반적인 파일 시스템 명령도 범위 안에서는 자동 승인된다.

claude --permission-mode acceptEdits

이미 Claude Code를 실행한 상태라면 Shift+Tab으로 모드를 전환할 수 있다. 기본 모드에서 한 번 누르면 acceptEdits로 바뀐다.

이 모드는 “Claude가 코드를 고치고, 나는 나중에 git diff로 검토하겠다”는 작업 방식에 잘 맞는다. 반대로 패키지 설치, 배포, 외부 경로 쓰기, 보호 경로 수정처럼 영향 범위가 큰 작업은 계속 확인을 요구한다.

기본값으로 쓰고 싶다면 설정 파일에 다음처럼 지정할 수 있다.

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

2. 반복 명령은 permission rule로 좁게 허용하기

매번 같은 명령을 승인하고 있다면 permission rule을 쓰는 편이 더 정확하다. /permissions에서 현재 규칙을 확인하고 관리할 수 있고, 프로젝트나 사용자 설정 파일에도 allow, ask, deny 규칙을 둘 수 있다.

예를 들어 빌드와 테스트는 자주 허용하되, 직접 push는 막고 싶다면 다음처럼 작성한다.

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

중요한 점은 규칙을 넓게 만들지 않는 것이다. BashBash(*)를 통째로 허용하면 승인 프롬프트는 줄어들지만, 임의의 셸 명령까지 허용하는 셈이 된다. 반복해서 쓰는 명령을 정확히 적고, 배포, push, 삭제, 권한 변경처럼 되돌리기 어려운 작업은 deny나 수동 승인 대상으로 남겨 두는 것이 안전하다.

3. 장시간 작업에는 auto를 검토하기

auto 모드는 Claude가 도구를 사용할 때 매번 사용자에게 묻지 않고, 별도의 안전성 분류기가 요청 범위를 벗어난 행동인지 확인하는 방식이다. 문서상 실행 방법은 다음과 같다.

claude --permission-mode auto

기존 글에 있던 --enable-auto-mode는 공식 CLI 옵션으로 확인되지 않는다. 현재 문서 기준으로는 --permission-mode auto를 써야 한다.

다만 auto는 “아무 작업이나 안전하게 맡기는 모드”가 아니다. 연구 프리뷰이고, Claude Code 버전, 계정 설정, 모델, 프로바이더 조건을 만족해야 한다. Team이나 Enterprise 환경에서는 관리자가 먼저 허용해야 할 수 있다. 또한 분류기는 배포, 마이그레이션, 권한 부여, 대량 삭제, 강제 push 같은 작업을 차단할 수 있다.

따라서 auto는 방향이 분명한 긴 작업에 적합하다. 예를 들어 “테스트가 통과할 때까지 컴포넌트 리팩터링을 반복해 줘”처럼 목표와 경계가 명확한 경우에 쓰고, 배포나 데이터 삭제처럼 영향이 큰 작업은 별도 확인을 남겨 두는 편이 좋다.

bypassPermissions는 일반 옵션으로 두지 않기

모든 프롬프트를 끄는 방법도 있다.

claude --permission-mode bypassPermissions

또는 같은 의미의 플래그를 쓸 수 있다.

claude --dangerously-skip-permissions

하지만 이 모드는 permission layer 자체를 우회한다. 공식 문서도 컨테이너, VM, 인터넷이 차단된 dev container처럼 호스트 시스템에 피해를 주기 어려운 격리 환경에서만 쓰라고 설명한다. 일반 로컬 프로젝트에서 편의성 때문에 기본값으로 두는 것은 권장하기 어렵다.

추천 조합

대부분의 개발 작업에서는 다음 조합이 가장 현실적이다.

  1. 평소에는 acceptEdits로 시작한다.
  2. 반복되는 빌드, 테스트, 포맷 명령만 permissions.allow에 추가한다.
  3. push, 배포, 삭제, 권한 변경은 deny나 수동 승인으로 남긴다.
  4. 긴 작업에서만 auto를 검토한다.
  5. bypassPermissions는 격리된 실험 환경에서만 사용한다.

이렇게 설정하면 승인 피로는 줄이면서도, Claude Code가 프로젝트 밖이나 운영 환경에 영향을 주는 작업을 마음대로 실행할 가능성은 낮출 수 있다.

확인한 문서