권한 모드

확인 날짜 안내

확인 날짜가 섞인 페이지다. 대부분은 원본 날짜 미상인 공식 문서·제품 가이드의 수집일(2026-10-18) 기준이다. Claude Code 권한 모드는 공식 문서 Claude Code 권한 모드로 채웠다. 블로그 Steering Claude Code(2026-06-18)의 문장 중 공식 문서가 확인한 것은 2026-10-18 기준으로 적었고, 블로그에만 근거한 문장에는 "(2026-06-18 기준)"을 남겼다. managed settings의 "유일한 방법"은 블로그가 매긴 평가라 "(블로그 평가)"로 표시하고, 에이전트 설계 글 효과적인 에이전트 만들기에서 온 "관련"의 한 문장은 권고(2024년 글)라 둘 다 날짜 계산에서 뺀다. 페이지 확인 날짜는 2026-09-16이다. 남은 가장 오래된 변하는 사실이 통합 공지·Help Center 문서의 Cowork 확인 방식(2026-09-16 기준)이기 때문이다.

처음 보는 용어(영어 설정 이름, 명령, 파일 형식)는 용어 사전에서 쉬운 풀이와 자세히 볼 페이지를 찾는다.

정의#

이 페이지는 에이전트가 무엇을 묻지 않고 하고 무엇 앞에서 확인을 받는지에 관한 설정과 안전장치를 모은다.

• Claude Code: 권한 모드(permission mode)는 한 세션에서 Claude가 먼저 묻지 않고 할 수 있는 동작을 정한다. Manual 모드에서는 파일 편집, 셸 명령, 네트워크 접근 대부분 앞에서 멈추고 묻는다. 자동 모드에서는 사람 대신 두 번째 모델인 분류기(classifier)가 동작을 검토한다. Claude Code 권한 모드
• Claude Cowork: 권한 모델(permissions model)이라 부르고, 원본 예로 "Act without asking" 모드가 있다. 권한 모델은 채팅마다 또는 설정에서 바꿀 수 있다. Claude Cowork 시작하기
• 두 제품의 모드는 별개다. 데스크톱 앱의 Cowork 탭은 Claude Code 권한 모드를 쓰지 않고, 따로 켜는 자체 권한 모드를 갖는다. 기본보다 넓은 모드가 계정에 켜지기 전에는 Cowork 탭에 모드 선택기가 아예 보이지 않는다. Claude Code 권한 모드 한편 2026-09-16 발표 글은 Cowork와 채팅이 하나의 Claude로 합쳐진다고 말한다(Pro·Max부터 순차 출시). 별도 탭 설명과의 상충은 출시 기간에 나뉜 화면과 통합 화면이 계정마다 함께 있는 것으로 해소했다(근거: Claude Cowork와 채팅 통합 도움말의 "your message box still shows "Chat" and "Cowork" options, you don't have it yet"). 두 주장은 Claude Cowork에 나란히 두었다. Claude Cowork와 채팅 통합 공지 통합 화면의 확인 방식은 메시지 입력창의 권한 설정 Auto·Manual(기본값)이다(2026-09-16 기준, 아래 Cowork 절). Claude Cowork와 채팅 통합 도움말 이름이 Claude Code의 Manual·auto와 같지만, 두 제품의 설정이 같은 것이라는 말은 원본에 없다.

Claude Code의 여섯 가지 모드 (2026-10-18 기준)#

각 모드는 편의와 감독 사이에서 다른 절충을 한다. 아래는 각 모드에서 권한 확인 창 없이 도는 범위다. Claude Code 권한 모드

근거: Claude Code 권한 모드. 모든 동작을 검토하는 모드는 CLI·IDE 확장·데스크톱 앱에서 Manual로 표시되고, 훅과 SDK가 쓰는 설정값은 default다. CLI는 manual을 별칭으로 받는다.

(2026-10-21 기준) 공식 권한 문서의 모드 표는 dontAsk에 조건 하나를 더한다: 물어야 할 호출을 모두 자동 거부하지만, 설치한 mod가 그중 일부를 승인할 수 있다. AskUserQuestion, requiresUserInteraction MCP 도구, 네트워크 경로 읽기, 조직이 ask로 정한 커넥터 도구(그 설정이 닿는 세션에서)는 허용해 두었어도 거부된다. Claude Code 권한 설정

모드별로 무엇을 묻는지, 어떻게 고르는지: Claude Code 권한 모드 고르기

모드와 권한 규칙의 관계 (2026-10-18 기준)#

• 모드는 기준선이고, 그 위에 권한 규칙(allow·ask·deny)을 얹어 특정 도구를 미리 허용하거나 막는다. Claude Code 권한 모드
• deny 규칙은 bypassPermissions를 포함한 모든 모드에서 막는다. allow 규칙은 bypassPermissions에서 효과가 없다. Claude Code 권한 모드 (2026-10-21 기준) 공식 권한 문서가 붙이는 조건 둘: (1) Bash 규칙은 명령 텍스트를 맞출 뿐이라 Bash(curl *) deny는 /usr/bin/curl …이나 sh -c 'curl …'을 막지 않는다("isn't a security boundary around the program"). (2) 설치한 mod가 tool.check로 승인할 때 deny 거부가 유지되는 것은 기기에 managed settings가 있거나 Team·Enterprise /login 세션일 때이고(기본값, 조직이 바꿀 수 있음), 둘 다 없으면 mod가 deny가 거부한 호출도 승인할 수 있다. Claude Code 권한 설정 → Claude Code 권한 규칙 문법
• (2026-10-21 기준) 규칙이 어느 설정 파일에 있느냐에 따른 차이: permissions.allow 같은 목록은 파일마다 덮어쓰지 않고 합쳐진다. 확인 창의 "Yes, and don't ask again"은 local 파일(.claude/settings.local.json)에 allow 규칙을 저장하는데, 이 allow는 project나 managed 파일의 ask 규칙보다 앞서지 않는다. 커밋한 .claude/settings.json의 allow 규칙은 팀원 각자가 폴더를 신뢰한 뒤에 적용되고 deny·ask는 바로 적용된다. 시작 모드 permissions.defaultMode의 auto·bypassPermissions는 project·local 파일에서 효과가 없다(v2.1.257 전에는 bypassPermissions가 어느 파일에서든 효과가 있었다). Claude Code 설정 파일과 우선순위 → Claude Code 설정 파일
• (2026-10-21 기준) settings reference가 키 단위로 확인하는 것: 규칙은 deny → ask → allow 순으로 평가하고 구체성과 상관없이 처음 맞는 규칙이 정한다. permissions.defaultMode 값은 default·acceptEdits·plan·auto·dontAsk·bypassPermissions와 default의 별칭 manual이고, VS Code 확장이 시작한 대화는 user·managed·--settings 값만 읽으며, 클라우드 세션은 acceptEdits·plan·default·auto만 따른다. 자동 모드를 없애는 disableAutoMode는 최상위 키(permissions.disableAutoMode로도 받음)이고 disableBypassPermissionsMode는 permissions 안의 키다. permissions.deny의 Read·Edit 규칙은 내장 파일 도구·알아보는 Bash 파일 명령·리디렉션 대상에만 적용되고 grep -r·임의 하위 프로세스에는 닿지 않는다. Claude Code 설정 키 전체 레퍼런스 → Claude Code 설정 키 레퍼런스
• (2026-10-21 기준) 규칙 문자열을 쓰는 법(Tool(specifier), 와일드카드 위치, 입력 파라미터 규칙, 경로 패턴 네 가지, 도구별 규칙)은 Claude Code 권한 규칙 문법에 원본 규칙 그대로 모았다. 공식 권한 문서는 규칙을 모델이 아니라 Claude Code가 강제하고, 프롬프트나 CLAUDE.md는 Claude가 하려는 일을 이끌 뿐 허용 범위를 바꾸지 않는다고 밝힌다. 프로젝트 파일의 allow 규칙이 언제 적용되는지는 작업 공간 신뢰. Claude Code 권한 설정
• 권한 모드는 동작 전에 물을지를 정하고, Bash 샌드박스와 바깥 격리 경계(컨테이너·VM)는 동작이 실행된 뒤 무엇에 닿을 수 있는지를 정한다. 둘은 독립적으로 동작하고 함께 쓸 수 있다. Claude Code 권한 모드 (2026-10-21 기준) 공식 Sandboxing 문서는 /sandbox가 권한 모드가 아니라고 못박는다. 샌드박스의 auto-allow는 샌드박스 경계가 명령을 가두기 때문에 Bash 명령을 승인하고, 자동 모드는 분류기가 동작을 검토한다. auto-allow는 권한 모드와 독립적이라 Manual 모드에서도 샌드박스 안 Bash 명령이 묻지 않고 돈다(예외: plan 모드, 명령별 허용 도메인을 단 자동 모드 명령, 자동 모드의 서버 측 분류기 검토). 샌드박스 안에서 실패한 명령을 샌드박스 밖에서 다시 돌릴 때 누가 승인하는지도 권한 모드가 정한다: bypassPermissions는 묻지 않고, Manual·acceptEdits는 확인 창, 자동 모드는 분류기, dontAsk는 거부. 샌드박스 명령이 허용 목록 밖 호스트에 연결할 때도 비슷하다: bypassPermissions는 허용, Manual·acceptEdits는 확인 창, 자동 모드는 명령이 그 호스트를 적고 분류기가 승인한 경우 말고는 거부, dontAsk는 거부. 단 strictAllowlist·allowManagedDomainsOnly가 켜져 있거나 deniedDomains에 있는 호스트는 모든 모드에서 거부된다. Claude Code 샌드박스 → 샌드박스

훅과 권한 모드 (2026-10-18 기준)#

공식 훅 가이드는 훅과 권한 모드의 관계를 한 방향으로만 강하다고 말한다. Claude Code 훅 가이드

• 조이기: PreToolUse 훅은 어떤 권한 모드 검사보다 먼저, dontAsk를 포함한 모든 모드에서 실행된다. permissionDecision: "deny"를 돌려주면 bypassPermissions나 --dangerously-skip-permissions에서도 도구를 막는다. 원본은 이것으로 사용자가 모드를 바꿔 우회할 수 없는 정책을 강제할 수 있다고 한다.
• 풀기는 못 한다: settings 파일과 플러그인 hooks/hooks.json의 훅은 권한 규칙이 허용하는 범위 너머로 풀지 못한다. "allow"는 settings의 deny 규칙을 넘지 못하고, 네트워크 경로 읽기·requiresUserInteraction MCP 도구·조직이 ask로 정한 커넥터 도구의 확인 창을 없애지 못한다. plan 모드에서 파일 편집을 "allow"해도 훅이 없을 때와 같은 처리를 받는다. (2026-10-21 기준) 공식 권한 문서의 세부: plan 모드에서 이 제한은 ExitPlanMode를 뺀 읽기 전용이 아닌 모든 호출에 걸리고, 훅이 돌려준 updatedInput은 적용되며, ExitPlanMode에 "allow"와 updatedInput을 돌려주면 확인 없이 돈다. 계획을 승인하거나 다른 모드로 바꾸면 풀린다. Claude Code 권한 설정
• 조건과 예외: 훅은 matcher가 맞춘 도구만 본다(예: Edit|Write는 셸 명령으로 고친 파일을 보지 않는다). 설치한 mod가 tool.check를 다루면 PreToolUse 훅이 막은 호출을 승인할 수 있다(plan 모드에서는 읽기 전용 호출만). Claude Code 훅 가이드 그 조건은 공식 권한 문서(2026-10-21) 기준으로 설명한다: 기기에 managed settings가 있거나 Team·Enterprise 로그인 세션이면 훅 차단이 기본으로 유지되고, 둘 다 없으면 mod가 훅 차단을 승인할 수 있다(훅 가이드 표현과의 관계는 훅의 ‘원본끼리 달랐던 점’ 상자). 자동 모드에서 mod가 승인한 호출은 분류기 검사 없이 돈다(mod가 --permission-prompt-tool·Agent SDK 권한 콜백을 우회할 수 없는 경우는 분류기가 먼저 검사). Claude Code 권한 설정 if 필드 거르기는 최선 노력이므로 확실한 허용·거부는 권한 규칙으로 하라고 원본이 말한다. 훅은 disableAllHooks로 꺼질 수 있다.
• PermissionRequest 훅은 확인 창에 대신 답하고 세션 권한 모드를 바꿀 수 있다(updatedPermissions의 setMode). bypassPermissions로의 전환은 세션을 bypass가 가능한 상태로 시작했을 때만 적용되고, permissions.disableBypassPermissionsMode나 restricted mode에서는 적용되지 않으며, defaultMode로 저장되지 않는다. → Claude Code 훅 설정 레시피
• (2026-10-18 기준) 공식 훅 레퍼런스가 더하는 것: Claude Code 훅 레퍼런스
  • 훅의 "ask"는 자동 모드에서도 확인 창을 강제한다. 분류기는 그 호출을 거부할 수는 있어도 조용히 승인하지 못한다. v2.1.211 전에는 분류기가 샌드박스 밖 Bash 명령을 훅이 요청한 확인 창 없이 승인할 수 있었다(그때도 훅의 "deny"는 항상 지켜졌다).
  • PreToolUse의 "allow"도 PermissionRequest의 behavior: "allow"도 deny·ask 규칙 평가를 건너뛰지 못하고, 훅이 updatedInput으로 바꾼 입력이 다시 그 규칙으로 평가된다. AskUserQuestion·ExitPlanMode는 답을 담은 updatedInput 없이 "allow"만으로는 안 된다.
  • PermissionRequest 훅은 확인 창이 없는 세션(예: 비대화형의 백그라운드 서브에이전트)에서도 돌고, 아무 훅도 결정하지 않으면 호출이 거부된다. 샌드박스 명령의 네트워크 요청 확인에는 돌지 않는다. 권한 갱신 destination은 session(메모리만), localSettings, projectSettings, userSettings 중 하나다.
  • PermissionDenied 훅은 자동 모드가 거부할 때만 돌고, 사용자의 수동 거부·PreToolUse 훅의 차단·deny 규칙 일치에는 돌지 않는다. retry: true는 거부를 되돌리지 않고 다시 시도해도 된다는 메시지만 더한다.
  • 훅 입력의 permission_mode는 Manual 모드를 "default"로 보낸다.
  • PostToolUse의 classifierContext가 분류기에 주는 무게는 훅이 어디 있는지에 따라 다르다. settings 파일·플러그인·스킬·에이전트 frontmatter의 훅이 준 메모는 검증되지 않은 애플리케이션 맥락으로 다뤄져 사용자 의도를 세우지 못하고, 메모가 사용자가 승인했다고 주장하면 분류기가 대화의 사용자 메시지와 대조한다. 실행 중 세션의 인프로세스 Agent SDK 콜백이 전한 사용자 진술만 사용자 의도로 볼 수 있되, 사용자 메시지로도 풀 수 없는 차단은 풀지 못한다. 메모는 호출당 2,000자까지다. 원본은 신뢰할 수 없는 도구 출력을 이 필드에 복사하지 말라고 경고한다.
  • 점검 순서는 Claude Code 차단 훅 단단하게 만들기, 이벤트별 결정 필드는 훅 이벤트 레퍼런스.

어떤 모드도 자동 승인하지 않는 것 (2026-10-18 기준)#

bypassPermissions를 포함해 어떤 모드에서도 Claude Code가 자동 승인하지 않는 동작이다. 모드마다 대신 무슨 일이 일어나는지(묻기 또는 거부)는 다르다. Claude Code 권한 모드

• 명시적 ask 규칙에 걸린 도구
• 조직이 ask로 정한 커넥터 도구(그 설정이 Claude Code에 닿는 세션에서) → MCP
• 사용자 상호작용이 필요한 도구: 내장 AskUserQuestion, requiresUserInteraction으로 표시된 MCP 도구
• 치명 경로(critical path)를 겨냥한 rm·rmdir. allow 규칙이나 PreToolUse 훅의 "allow"로도 승인되지 않는다
• 세션 간 메시지 안전장치
• permissions.blockReadsOutsideWorkingDirectories가 켜진 동안 작업 디렉터리 밖 읽기(v2.1.257 이상)

(2026-10-21 기준) 이 목록 밖이지만 비슷하게 다뤄지는 것: Read·Grep·Glob의 네트워크 경로 읽기(Windows UNC, macOS·Linux /net 자동 마운트)는 allow 규칙, 훅의 "allow", 자동 모드 분류기 어느 것도 확인을 없애지 못하고 dontAsk에서는 거부된다(v2.1.292 이상). 단 bypassPermissions와 bypass를 쓸 수 있는 대화형 터미널 plan 세션에서는 묻지 않고 읽는다. Claude Code 권한 설정 → Claude Code 권한 규칙 문법

자동 모드와 분류기 (2026-10-18 기준)#

• 무엇을 하나: 별도 분류기 모델이 동작을 실행 전에 검토해, 요청 범위를 넘어서는 일, 모르는 인프라를 겨냥한 일, Claude가 읽은 적대적 콘텐츠에 이끌린 것으로 보이는 일을 막는다. 명시적 ask 규칙은 여전히 확인 창을 띄운다. Claude Code 권한 모드
• 안전 보장이 아니다. 원본 경고: 자동 모드는 확인 창을 줄이지만 안전을 보장하지 않는다. 전체 방향을 믿는 작업에 쓰고, 민감한 작업의 검토를 대신하는 용도로 쓰지 말라고 한다. Claude Code 권한 모드
• 판정 순서: (1) allow·ask·deny 규칙에 맞으면 바로 결정(보호 경로 쓰기, 치명 경로 삭제, requiresUserInteraction MCP 도구 등은 예외), (2) 읽기 전용 동작과 작업 디렉터리 안 파일 편집은 자동 승인(보호 경로 쓰기, 작업 디렉터리 밖 첫 읽기 제외), (3) 나머지는 분류기로, (4) 막히면 Claude가 이유(예: [Data Exfiltration])를 받는다. Claude Code 권한 모드
• 자동 모드에 들어가면 넓은 allow 규칙이 빠진다: Bash(*), Bash(python*) 같은 인터프리터 와일드카드, 패키지 매니저 run 명령, Agent·Monitor allow 규칙. Bash(npm test) 같은 좁은 규칙은 남고, 자동 모드를 나가면 복원된다. Claude Code 권한 모드 (2026-10-21 기준) 공식 자동 모드 설정 문서는 셸 규칙 쪽을 이렇게 적는다: 좁은 Bash·PowerShell allow 규칙은 분류기보다 먼저 판정되고(명령에 명령별 허용 도메인이 붙은 경우 제외), 그래서 규칙 접두어가 예상하지 못한 파괴적 인자가 분류기에 보이지 않고 통과할 수 있다. 모든 셸 명령을 분류기에 보내려면 autoMode.classifyAllShell: true(치명 경로 삭제는 예외). Claude Code 자동 모드 설정 → Claude Code 자동 모드 설정하기
• 분류기가 보는 것: Claude Code가 직접 보내는 분류기 요청에는 사용자 메시지, 읽기 전용 조회를 뺀 도구 호출, CLAUDE.md 내용이 들어가고, 도구 결과는 빠진다. 그래서 파일이나 웹 페이지의 적대적 콘텐츠가 분류기를 직접 조종할 수 없다. 별도의 서버 측 검사가 들어오는 도구 결과를 Claude가 읽기 전에 스캔한다. Claude Code 권한 모드 → 메모리(CLAUDE.md)
• 기본 차단·허용: 기본 차단 예는 curl | bash처럼 코드 내려받아 실행, 민감 데이터의 외부 전송, 운영 배포·마이그레이션, 클라우드 저장소 대량 삭제, IAM·저장소 권한 부여, force push, git reset --hard 같은 미커밋 변경 폐기, terraform destroy, 사람이 승인하지 않은 PR 병합, 운영 기능 플래그 변경, 실제 자격 증명 출력이다. 기본 허용 예는 작업 디렉터리 안 파일 작업, lock 파일에 선언된 의존성 설치, 읽기 전용 HTTP 요청, 작업 중인 저장소의 브랜치로 push다. 전체 목록은 claude auto-mode defaults로 JSON 출력한다. Claude Code 권한 모드 → Claude Code 권한 모드 고르기 (2026-10-21 기준) 공식 자동 모드 설정 문서가 push에 붙이는 조건: 기본 허용은 작업 저장소의 모든 브랜치(기본 브랜치 포함)로의 push와 PR 생성이지만, production·release·gh-pages처럼 이름이 배포·공개 대상을 가리키는 기본 브랜치 아닌 브랜치는 이 기본에서 빠져 분류기가 따로(운영 배포로서도) 판단하고, push 내용도 검사해 force push, 비밀값이 커밋에 들어가는 것, CI나 배포 파이프라인이 돌릴 때 비밀값을 저장소 밖으로 보낼 변경은 계속 막는다. Claude Code 자동 모드 설정
• 대화로 말한 경계와 승인: "push하지 마", "배포 전에 내가 검토할 때까지 기다려"는 분류기의 차단 신호가 되고, 나중 메시지로 풀 때까지 유지된다. Claude가 조건이 충족됐다고 스스로 판단해도 풀리지 않는다. 하지만 규칙으로 저장되지 않고 매번 대화 기록에서 다시 읽으므로, 컴팩션이 그 메시지를 지우면 사라질 수 있다. 확실히 보장하려면 deny 규칙을 쓴다. 반대로 막힌 동작을 허용하려면 동작과 위험 요소(예: force push할 브랜치)를 구체적으로 말해야 하고, 그 승인은 기본적으로 그 동작 하나에만 미친다. Claude Code 권한 모드 → 장기 작업 컨텍스트 관리 (2026-10-21 기준) 공식 자동 모드 설정 문서는 의도가 닿는 범위를 분류기 안의 네 단계 우선순위로 적는다: hard_deny 규칙은 무조건 막아 사용자 의도와 allow 예외가 닿지 않고, soft_deny는 그다음 막으며, allow가 맞는 soft_deny의 예외가 되고, 끝으로 사용자 메시지가 Claude가 하려는 바로 그 동작을 직접·구체적으로 말하면 남은 soft block을 넘는다("저장소 정리해 줘"는 force push를 허락하지 않는다). Claude Code 자동 모드 설정
• 설정 (2026-10-21 기준): 분류기에게 신뢰 인프라와 규칙을 알려 주는 곳은 autoMode 블록(environment, allow, soft_deny, hard_deny, classifyAllShell)이다. 기본 신뢰 범위는 작업 디렉터리와 현재 저장소에 설정된 remote뿐이라, 회사 소스 관리 조직으로의 push나 팀 버킷 쓰기는 environment에 넣을 때까지 막힌다. 분류기는 autoMode를 ~/.claude/settings.json, managed settings, --settings·Agent SDK 인라인에서만 읽고, 프로젝트 .claude/settings.json·.claude/settings.local.json에서는 읽지 않는다(저장소가 allow 규칙을 주입하지 못하게). 범위별 항목은 합쳐진다. 개발자는 managed 항목을 지우지 못하지만, 개발자가 더한 allow가 조직 soft_deny를 넘을 수 있어 원본은 이 합치기를 "not a hard policy boundary"라 부른다. 원본은 분류기를 권한 시스템 뒤에 도는 두 번째 관문으로 설명하고, 사용자 의도나 분류기 설정과 상관없이 막아야 할 동작은 managed settings의 permissions.deny로 막으라고 한다. Claude Code 자동 모드 설정 → Claude Code 자동 모드 설정하기
• 제공자 (2026-10-21 기준): 공식 자동 모드 설정 문서는 자동 모드를 모든 제공자(Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud의 Agent Platform, Microsoft Foundry, 로그인한 Claude apps gateway 세션)에서 모든 사용자가 쓸 수 있다고 적는다. 쓸 수 없다고 나오면 지원 모델과 Team·Enterprise 플랜의 조직 단위 통제를 포함한 전체 요건을 확인하라고 한다. Claude Code 자동 모드 설정
• 물러설 때: 연속 3회 또는 합계 20회 차단이면 자동 모드가 멈추고 다시 묻는다(바꿀 수 없는 기준). 막힌 동작은 /permissions의 Recently denied 탭에서 r로 수동 승인해 다시 시도한다. 분류기나 서버가 판정을 주지 못하면 실행하지 않고 거부한다. Claude Code 권한 모드
• 서브에이전트도 검사한다: 시작 전 위임 내용, 실행 중 각 동작, 끝난 뒤 작업과 보고서를 본다. 자동 모드에서는 서브에이전트 frontmatter의 permissionMode가 무시된다. Claude Code 권한 모드 → 서브에이전트
• (2026-10-18 기준) 공식 서브에이전트 문서의 permissionMode 규칙: 두지 않으면 메인 대화 모드를 물려받는다. 메인이 bypassPermissions·acceptEdits·auto면 서브에이전트도 그 모드로 돌고 설정값은 무시된다. 메인이 default·dontAsk·plan이면 설정값으로 돌되, bypassPermissions를 설정하면(v2.1.267 이상) 또는 쓸 수 없는 auto(disableAutoMode, 모델 미지원)를 설정하면 메인 모드를 유지한다. 그래서 v2.1.267 이상에서는 서브에이전트가 bypassPermissions로 도는 것은 메인도 그 모드일 때뿐이다. 플러그인 서브에이전트는 이 필드를 무시한다. 백그라운드 서브에이전트의 확인은 메인 세션에 뜨고, 그 한 번을 넘는 승인은 세션 전체에 적용된다. 다른 에이전트의 메시지는 대기 중인 권한 확인의 승인이 되지 않는다. Claude Code 서브에이전트 → 서브에이전트 정의 파일 레퍼런스
• 명확화 질문: 자동 모드는 Claude가 명확화 질문으로 멈추지 않고 계속 일하도록 이끈다. 프롬프트나 스킬이 질문에 명시적으로 기대면 여전히 묻는다. 확인 창은 그대로 두고 자율성만 높이려면 Proactive 출력 스타일을 쓴다. Claude Code 권한 모드 → 출력 스타일 공식 출력 스타일 문서(2026-10-18 기준)는 Proactive로 바꿔도 권한 모드가 바뀌지 않아 권한 확인 창이 전과 똑같이 뜬다고 한다. 이 스타일이 지우거나 공유·운영 시스템을 바꾸기 전에 대화로 확인하라고 하는 것은 Claude가 따르는 지시일 뿐, 권한 확인 창과는 별개다. Claude Code 출력 스타일

보호 경로와 치명 경로 (2026-10-18 기준)#

• 보호 경로(protected paths): 저장소 상태와 Claude 자신의 설정이 실수로 망가지지 않도록, bypassPermissions(그리고 bypass를 쓸 수 있는 대화형 터미널 plan 세션) 밖에서는 쓰기를 자동 승인하지 않는 경로다. .git, .vscode, .claude(일부 예외), .husky 같은 디렉터리와 .gitconfig, .bashrc·.zshrc, .npmrc, .mcp.json, .claude.json 같은 파일이 들어간다. 모드별 처리는 Manual·acceptEdits는 묻기, auto는 분류기, dontAsk는 거부, bypassPermissions는 허용이다. 설정 파일의 allow 규칙(예: Edit(.claude/**))으로 미리 허용되지 않는다. Claude Code 권한 모드
• 치명 경로(critical paths): rm·rmdir로부터 지키는 디렉터리다. 파일 시스템 루트, 최상위 디렉터리(/usr, /etc 등), 홈 디렉터리, 작업 디렉터리와 그 부모 등이다. 원본은 이것을 모델 오류에 대비한 차단기(circuit breaker)라 부른다. Manual·acceptEdits는 묻고, auto는 터미널에서 2분 제한으로 묻고 그 밖에서는 거부하며, dontAsk는 거부, bypassPermissions는 묻는다. auto·bypassPermissions의 이 처리는 v2.1.281 이상이고, CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1이면 auto에서는 분류기로 넘어간다. Claude Code 권한 모드

Claude Cowork의 안전장치 (원본 범위)#

원본은 확인 장치를 세 가지 표현으로 말한다. 표현의 강도를 원문 그대로 옮긴다.

근거: Claude Cowork 시작하기 (2026-10-18 확인)

마지막 줄은 "지침"이다. 원본은 이 항목들을 기술적으로 막는다고 말하지 않는다.

통합 공지의 확인 방식 (2026-09-16 기준). Cowork와 채팅을 합친 발표 글은 Claude가 사용자에게 확인받는 방식을 고를 수 있다고 말한다. 기본값은 Claude가 동작하기 전에 묻는 것("By default, Claude asks before taking an action")이고, 계속 일하다가 더 살펴볼 일이 있을 때만 확인받도록 켤 수 있다("check in only when something needs a closer look"). 원본은 "최종 결정은 사용자에게 있다(You keep the final say)"고 덧붙인다. Claude Cowork와 채팅 통합 공지

• 이 설정의 이름, 위치, 무엇이 "더 살펴볼 일"인지, 위 표의 민감 동작 확인이 이 설정에서도 그대로 걸리는지는 공지에 없다. 위 제품 가이드의 "Act without asking"과 같은 설정인지도 확인되지 않는다.

Help Center 문서의 권한 설정 (2026-09-16 기준). 같은 날 수정된 Help Center 문서는 이 설정의 이름과 위치를 적는다. 메시지 입력창의 권한 설정이 Claude가 얼마나 독립적으로 일할지 정한다. Claude Cowork와 채팅 통합 도움말

• 설정은 언제든 바꿀 수 있고 대화 전체에 적용된다. 작업 중에 멈추거나 방향을 바꿀 수 있다. Claude Cowork와 채팅 통합 도움말
• 원본은 메시지 보내기나 중요한 파일 바꾸기처럼 결과가 실제로 남는 일은 가까이서 Claude가 하는 일을 검토하라고 권한다. Auto가 그런 일을 막는다고 말하지 않는다. Claude Cowork와 채팅 통합 도움말
• 로컬 파일은 기본적으로(by default) 영구 삭제 전에 묻는다. 이 기본값을 바꿀 수 있는지, 어떻게 바꾸는지는 원본에 없다. 로컬 파일, 내장 브라우저, 컴퓨터 사용은 Claude Desktop이 열려 있는 동안에만 닿는다. Claude Cowork와 채팅 통합 도움말
• 자동 안전 검사가 무엇을 검사하고 막는지, 위 표의 민감 동작(다운로드·삭제·공유 설정 변경) 확인이 Auto에서도 걸리는지는 이 문서에 없다(원본은 안전 사용 도움말로 넘긴다).

ChatGPT Work의 승인과 멈춤 (원본 범위, 2026-10-18 기준)#

ChatGPT Work 시작 문서는 권한 모드라는 이름의 설정을 다루지 않는다. 원본이 말하는 통제 장치는 다음이다. ChatGPT Work 시작하기

근거: ChatGPT Work 시작하기

• Local computer access with Work Cloud를 끄면 실행 중인 턴이 중단되고, 한 턴 도중에는 로컬에서 클라우드 실행으로 바뀌지 않는다. 동기화를 켜기 전에 워크스페이스 관리자가 정책 요건과 설정 단계를 검토할 수 있다고 원본은 안내한다. ChatGPT Work 시작하기
• 편집자 해석: 원본이 컨테이너가 "엔터프라이즈 실행 요건을 강제하지 못한다"고 적은 대목으로 보아, 로컬 컴퓨터에 건 실행 요건은 클라우드로 이어진 턴에는 따라가지 않는다고 볼 수 있다. ChatGPT Work 시작하기

접근 범위도 권한이다#

• 파일(Cowork): 폴더를 명시적으로 연결하기 전에는 어떤 파일도 보지 않는다. Claude Cowork 시작하기
• 앱(Cowork): 사용자가 인증한 MCP 커넥터를 통해 연결한다. Claude Cowork 시작하기
• 파일(Claude Code, 2026-10-18 기준): blockReadsOutsideWorkingDirectories가 꺼져 있으면 자동 모드에서 작업 디렉터리 밖 읽기도 묻지 않고 돌지만, Read·Grep·Glob이 처음 밖의 경로를 읽을 때 한 번 묻는다. 여기서 "No, and block reads outside the working directories from now on"을 고르면 사용자 설정에 차단이 저장돼 이후 모든 세션·모드에서 파일 도구가 밖을 읽지 않는다. 비대화형 -p와 백그라운드 세션에서는 이 질문이 뜨지 않는다. Claude Code 권한 모드
• 작업 디렉터리(Claude Code, 2026-10-21 기준): 기본 접근은 시작한 디렉터리(세션의 주 작업 디렉터리)다. 시작 때 --add-dir <path>, 세션 중 /add-dir, 지속 설정 additionalDirectories로 넓힌다. 추가 디렉터리의 파일은 같은 규칙을 따라 네트워크 경로 검사 말고는 묻지 않고 읽히고, 편집은 현재 모드를 따른다. 추가 디렉터리는 파일 접근만 주고 구성 루트가 되지 않는다: --add-dir·/add-dir로 더한 곳에서만 스킬(실시간 반영)·명령 파일·서브에이전트, 설정의 enabledPlugins·extraKnownMarketplaces 키, (CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1일 때) CLAUDE.md·.claude/rules/·CLAUDE.local.md를 읽고, 설정 파일의 permissions.additionalDirectories는 파일 접근만 준다. 대부분의 네트워크 경로(UNC 공유 등)는 작업 디렉터리로 더할 수 없다. /cd <path>는 대화를 유지한 채 주 작업 디렉터리를 옮기고, 옮기는 즉시 새 디렉터리의 프로젝트 설정(권한 규칙·훅)·플러그인·스킬·서브에이전트·env를 적용한다(v2.1.246 이상). 조건이 둘 있다. 처음 가는 디렉터리면 먼저 작업 공간 신뢰를 묻고(확인 창이 그 디렉터리 설정이 켤 allow 규칙·추가 디렉터리·훅·헬퍼 명령을 나열한다), 거절하면 세션은 원래 디렉터리에 그대로 남는다. 새 디렉터리의 .mcp.json 서버는 시작 때와 같은 서버 승인을 거친다. 이전 디렉터리 설정의 env 값은 계속 유효하고 새 값이 그 위에 얹히며, 옮기면서 켜진 훅의 ${CLAUDE_PROJECT_DIR}는 세션을 시작한 프로젝트 루트를 그대로 가리킨다. Claude Code 권한 설정 → 작업 공간 신뢰, Claude Code 권한 규칙 문법(Cd 규칙)

작업 중 통제#

• Cowork: 단계마다 하는 일과 추론을 보여 주므로 사용자가 따라갈 수 있고, 방향이 틀리면 중간에 끼어들어 바로잡을 수 있다. Claude Cowork 시작하기
• Claude Code(2026-10-18 기준): CLI에서는 Shift+Tab으로 언제든 모드를 바꾸고, 상태 표시줄에 현재 모드가 뜬다(⏸ manual mode on, ⏵⏵ auto mode on 등). Claude Code 권한 모드
• Claude Code(2026-10-18 기준): Esc를 누르면 즉시 멈추고 실행 중인 도구 호출이 취소된다. 멈추지 않고 정정을 입력해 Enter를 누르면, 실행 중인 도구 호출이 끝난 뒤 같은 턴 안에서 읽고 다음 단계 전에 조정한다. Claude Code 작동 방식 → Claude Code 세션·체크포인트 다루기

체크포인트와 권한: Claude Code의 두 안전장치 (2026-10-18 기준)#

공식 "How Claude Code works" 문서는 안전장치를 두 가지로 설명한다: 체크포인트는 파일 변경을 되돌리게 하고, 권한은 Claude가 묻지 않고 할 수 있는 일을 정한다. Claude Code 작동 방식

근거: Claude Code 작동 방식, Claude Code 권한 모드

원본은 체크포인트할 수 없는 원격 동작을 권한 모드와 권한 규칙으로 통제한다고 말한다. Claude Code 작동 방식 편집자 해석: 그래서 "되돌릴 수 있으니 괜찮다"는 설명은 내 컴퓨터의 파일 편집에만 맞고, 배포·외부 API 호출처럼 바깥에 흔적을 남기는 일은 처음부터 묻게 하는 쪽(모드·ask·deny 규칙)으로 통제하는 편이 맞다고 볼 수 있다. 근거는 위 원본 문장이다. 다만 규칙과 분류기에도 한계가 있다(위 "모드와 권한 규칙의 관계", "자동 모드와 분류기" 절). 공식 권한 모드 문서는 대화로 말한 경계("배포 전에 기다려" 같은)가 컴팩션으로 사라질 수 있으니, 확실한 보장이 필요하면 deny 규칙을 더하라고 한다. Claude Code 권한 모드

같은 문서는 Shift+Tab 순환으로 네 모드(Auto, Manual, Accept edits, Plan)를 소개하고, 자동 모드가 v2.1.283 이상에서 대화형 터미널·VS Code 세션의 내장 시작 모드이고 그 이전 버전에서는 Pro·Max·Team 플랜에서만 그렇다고 적는다. 위 여섯 모드 표, 공식 권한 모드 문서의 설명과 같은 방향이다. 믿을 만한 명령(npm test, git status 등)은 .claude/settings.json에서 미리 허용할 수 있다. Claude Code 작동 방식 → Claude Code 권한 모드 고르기

Claude Code 스킬과 권한 (2026-10-18 기준)#

스킬이 권한과 맞닿는 지점이다. Claude Code 스킬

• allowed-tools는 허용만 한다. 스킬을 부른 그 턴 동안 적힌 도구를 묻지 않고 쓰게 하고, 다음 메시지를 보내면 사라진다. 다른 도구를 막지는 않으며, 적히지 않은 도구는 평소 권한 설정을 따른다. 세션 전체에 미리 허용하려면 권한 설정에 allow 규칙을 더한다. Claude Code 스킬
• 작업 공간 신뢰와 무관하다. 한 번도 신뢰하지 않은 폴더의 -p 실행에서도 프로젝트 스킬의 allowed-tools가 적용된다. 스킬이 스스로에게 넓은 도구 권한을 줄 수 있으므로, 저장소에 체크인된 스킬의 allowed-tools는 그 저장소에서 Claude Code를 돌리기 전에 검토한다. 조직은 managed settings의 allowManagedPermissionRulesOnly로 프로젝트·개인 스킬의 allowed-tools를 무시하게 할 수 있다(v2.1.282 이상). Claude Code 스킬 → Claude Code 관리자 권한 통제
• disallowed-tools 는 스킬이 활성인 동안 도구를 풀에서 뺀다. 모든 스킬과 프롬프트에 걸쳐 막으려면 권한 설정의 deny 규칙을 쓴다. Claude Code 스킬
• 스킬 자체를 권한 규칙으로 다룬다. /permissions에서 Skill을 deny하면 모든 스킬이 꺼진다. Skill(commit)은 정확히, Skill(review-pr *)는 접두어로 맞춘다. Claude Code 스킬
• 동적 컨텍스트 명령은 묻지 않고 규칙으로만 판정된다. 스킬의 !`명령`은 렌더 중 권한 확인 창을 띄우지 않는다. deny 규칙에 걸리면 호출이 중단되고, 자동 모드 밖에서는 허용이 아닌 결과(평소라면 묻는 규칙 포함)도 중단된다. 자동 모드에서는 Claude에게 그 명령을 먼저 실행하라는 지시와 함께 스킬이 로드되고, Claude의 호출이 자동 모드의 평소 검사를 거친다. Claude Code 스킬 → 스킬 문제 해결
• 부작용 있는 워크플로는 사용자만 부르게 한다. disable-model-invocation: true를 단 /deploy를 Claude가 부르려 하면 Claude Code가 막고 다른 방법으로 배포 단계를 재현하지 말라고 지시한다. Claude Code 스킬

관련#

• (2024년 글) 왜 에이전트의 자율에 통제가 필요한가: Anthropic의 에이전트 설계 글은 에이전트가 여러 턴 동안 움직일 수 있으므로 그 의사결정을 어느 정도 신뢰해야 하고, 자율성은 신뢰할 수 있는 환경에서 작업 규모를 키우는 데 이상적이지만 더 높은 비용과 오류가 쌓일 가능성을 뜻한다고 말한다. 그래서 샌드박스 환경에서의 폭넓은 시험과 적절한 가드레일을 권한다. 이 글은 권장이며, 어떤 가드레일이 무엇을 막는지는 정하지 않는다. 체크포인트나 막혔을 때 사람의 피드백을 위해 멈추게 하고, 최대 반복 횟수 같은 정지 조건을 두는 것도 흔하다고 적는다. 효과적인 에이전트 만들기 → 에이전트 시스템 패턴 고르기
• 세팅 순서에서의 위치: Claude Cowork 시작 세팅 (첫 작업 전 세팅 두 번째)
• ChatGPT Work 첫 업무에서 검토 지점을 프롬프트에 적는 방법: ChatGPT Work 첫 업무 위임
• 관리자가 조직 단위로 모드와 규칙을 통제하는 방법: Claude Code 관리자 권한 통제
• 규칙 문자열 문법과 도구별 규칙: Claude Code 권한 규칙 문법. 저장소가 주는 allow 규칙이 신뢰 전에 적용되지 않는 이유: 작업 공간 신뢰
• 규칙을 둘 설정 파일과 우선순위: Claude Code 설정 파일, 안 먹을 때 점검은 Claude Code 설정 바꾸기·확인·문제 해결
• Claude Code 쪽에서 "매번 지켜져야 하는 규칙"을 강제하는 장치는 훅이다. Claude Code 확장 기능 개요
• (2026-10-18 기준) 반드시 일어나면 안 되는 일에 지시는 잘못된 도구이고, 결정론적 강제 수단은 훅과 권한(permissions)이다. Steering Claude Code 공식 권한 모드 문서도 같은 방향이다: 대화로 말한 경계는 컴팩션으로 사라질 수 있으니 확실한 보장은 deny 규칙으로 하라고 하고, deny 규칙은 모든 모드에서 막으며, 훅(PreToolUse, PermissionRequest)을 사용자 정의 권한 로직으로 소개한다. Claude Code 권한 모드 → Claude Code 확장 기능 고르기
• 블로그 글(2026-06-18): managed settings는 관리자가 배포하고 사용자 로컬 설정으로 덮어쓸 수 없으며(아래 공식 배포 문서가 조건과 함께 확인, 2026-10-18 기준), 조직 전체의 결정론적 가드레일을 강제하는 유일한 방법이다(블로그 평가). Steering Claude Code 공식 권한 모드 문서(2026-10-18)는 이 중 일부만 확인한다: permissions.defaultMode는 managed·project 값이 ~/.claude/settings.json보다 우선하고, managed settings의 disableAutoMode가 켜지면 --permission-mode auto로 시작해도 Manual로 시작한다. "유일한 방법"이라는 일반 주장은 확인하지 않는다. Claude Code 권한 모드 공식 managed settings 배포 문서(2026-10-18)는 "덮어쓸 수 없다"를 설정 파일 기준으로 확인한다: user·project·local·--settings 값은 managed 값을 덮어쓰지 못하되, 몇몇 보안 민감 예외에서는 낮은 레벨의 더 엄격한 값이 효력을 갖는다. 같은 문서는 이 규칙 밖의 경우(managed model·autoCompactWindow는 기본값, 로컬 관리자의 관리 출처 수정, Claude Code 밖의 도구)도 적고, "유일한 방법"이라고는 말하지 않는다. Claude Code managed settings 배포 → managed settings
• 조직 단위에서는 managed settings가 강제 층이다. 공식 메모리 문서는 특정 도구·명령·파일 경로 차단(permissions.deny), 샌드박스 격리(sandbox.enabled), 로그인 제한은 managed settings에 두고, 코드 스타일·데이터 취급 안내·행동 지시는 managed CLAUDE.md에 두라고 구분한다. settings 규칙은 Claude의 결정과 상관없이 클라이언트가 강제하고, CLAUDE.md 지시는 행동을 이끌 뿐 강제 층이 아니다(2026-10-18 기준). Claude Code 메모리 → 메모리(CLAUDE.md)