이 페이지의 목차
이 페이지의 목차
확인 날짜 안내
원본 날짜 미상인 공식 문서들의 수집일(2026-10-18) 기준이다. 키 이름·위치·기본값 일부는 settings reference(수집 2026-10-21, Claude Code 설정 키 전체 레퍼런스)로 다시 확인했고, 그 문장에는 날짜를 적었다. 설정 키와 버전 조건은 빨리 바뀌므로 대외 자료에 쓰기 전에 공식 문서를 다시 확인한다. 키별 타입·기본값·Scope 표는 Claude Code 설정 키 레퍼런스.
조직 관리자가 Claude Code의 권한 모드와 규칙(allow·ask·deny, 용어 사전)을 어떻게 통제하는지 정리한다. 금융·공공 고객이 묻는 "에이전트가 마음대로 하지 않나"에 답할 때 근거로 쓰도록, 원본 사실을 질문 단위로 묶었다. 모드 자체의 동작은 Claude Code 권한 모드 고르기, 개념은 권한 모드, 규칙 문자열 문법은 Claude Code 권한 규칙 문법, 저장소 설정이 신뢰 전에 무엇을 하는지는 작업 공간 신뢰에 있다.
준비물(필요한 것)#
| 필요한 것 | 내용 |
|---|---|
| managed settings를 기기에 배포하는 수단 | 이 페이지의 설정 대부분은 managed settings |
| 조직 계정 또는 관리 설정 | 설치한 mod가 승인하는 호출에도 deny가 유지되는 것은 기기에 managed settings가 있거나 Team·/ 세션일 때다 |
| 버전 확인 | 키마다 버전 조건이 붙는다. 예: 실행 중인 자동 모드 세션이 disableAutoMode 배포를 받아 빠져나오는 것은 v2.1.251 이상, block가 Bash 읽기 명령까지 묻게 하는 것은 v2.1.257 이상 |
| 샌드박스는 macOS· |
1. "에이전트가 마음대로 하지 않나"에 답하는 근거#
| 고객 질문 | 원본이 말하는 사실 | 근거 |
|---|---|---|
| 기본으로 뭘 묻나 | Manual 모드는 파일 편집, 셸 명령, 네트워크 접근 대부분 앞에서 멈추고 묻는다. 묻지 않고 도는 것은 읽기뿐이다 | Claude Code 권한 모드 |
| 아무리 풀어도 막히는 게 있나 | deny 규칙은 bypassPermissions를 포함한 모든 모드에서 막는다. 단 명령Bash(git push *) deny는 git -C . push origin main을, Bash(rm *)는 /·bash -c 'rm -rf build/를 막지 않는다. 또 설치한 mod가 승인할 때 deny가 유지되는 것은 기기에 managed settings가 있거나 Team·/ 세션일 때이고--allowedTools로도 못 푼다) | Claude Code 권한 모드, Claude Code 권한 설정 → Claude Code 권한 규칙 문법 |
| 모드를 풀어도 자동 승인되지 않는 게 있나 | ask 규칙에 걸린 도구, 조직이 ask로 정한 커넥터 도구rm·rmdir는 어떤 모드에서도 자동 승인되지 않는다 | Claude Code 권한 모드 |
| 관리자 설정을 사용자가 덮어쓸 수 있나 | 사용자·--settings 값은 managed 값을 덮어쓰지 못한다model·autoCompactWindow는 기본값일 뿐이고, 기기 로컬 관리자인 개발자는 관리 출처 자체를 고칠 수 있으며, managed settings는 Claude Code만 묶는다defaultMode). 엄격한 낮은 값이 이기는 키 11개disable, permissions., 가장 낮은 maxEffortLevel)는 Settings 문서 | Claude Code managed settings 배포, Claude Code 설정 파일과 우선순위 → managed settings, Claude Code 설정 파일 |
| 사용자가 위험한 모드를 마음대로 켤 수 있나 | 관리자는 managed settings로 자동 모드를 없애고disableAutoMode) bypassPermissions를 막을 수 있다disable). 프로젝트 설정., .)에 넣은 auto·bypassPermissions 시작 모드는 효과가 없다. 단 user 설정이나 한 세션의 --permission-mode로는 여전히 고를 수 있고bypassPermissions가 어느 파일에서든 효과가 있었다 | Claude Code 권한 모드, Claude Code 설정 파일과 우선순위 |
모드를 bypassPermissions로 바꿔도 회사 규칙이 지켜지나 | PreToolUse 훅은 어떤 권한 모드 검사보다 먼저 모든 모드에서 실행되고, "deny"를 돌려주면 bypassPermissions·--dangerously-skip-permissions에서도 도구를 막는다. 단 훅은 matcher가 맞춘 도구만 본다Edit|Write 훅은 셸 명령으로 고친 파일을 보지 않는다). 설치한 mod가 tool.로 훅 차단을 넘을 수 있는지는 세션 조건에 달렸다disableAllHooks로 꺼질 수 있다. 원본은 확실한 허용·if 거르기가 아니라 권한 규칙으로 하라고 한다 | Claude Code 훅 가이드, Claude Code 권한 설정 → 훅 |
| 저장소를 클론하면 그 저장소가 스스로 권한을 줄 수 있나 | 프로젝트 .의 permissions.와 additional는 그 폴더의 작업 공간 신뢰 대화상자를 수락한 뒤에만 적용되고, claude -p·-p·env, apiKeyHelper 같은 헬퍼, 프로젝트 스킬의 훅과 allowed-tools는 쓰이고, -p·. 서버가 묻지 않고 연결된다 | Claude Code 권한 설정 → 작업 공간 신뢰 |
| Cowork 쪽 셸 명령도 막을 수 있나 | Claude Desktop의 Cowork 세션은 mcp__workspace__bash·mcp__를 쓰는데, 도구 전체를 이름으로 막는 Bash·WebFetch deny가 이 도구에도 적용돼 managed Bash deny가 Cowork의 셸 명령을 막는다. allow는 넘어가지 않는다Bash allow는 mcp__workspace__bash에 적용되지 않음). 범위를 둔 규칙Bash(rm *) 등)이 Cowork 도구에 적용되는지는 원본이 말하지 않는다 | Claude Code 권한 설정 → Claude Cowork |
| 셸 명령이 실제로 닿는 파일· | ~/.·~/. 같은 자격 증명 파일도 읽게 두며, 파일 도구·!로 친 명령excludedCommands는 밖에서 돈다. Windows 네이티브에서는 샌드박스가 돌지 않는다. 원본은 샌드박스가 "완전한 격리 경계가 아니다"라고 하고, 내장 프록시가 TLS 내용을 검사하지 않아 넓은 도메인 허용이 유출 경로가 될 수 있다고 경고한다 | Claude Code 샌드박스 → 샌드박스 |
| 자동 모드는 무엇을 막나 | 분류기가 요청 범위를 넘는 일, 모르는 인프라를 겨냥한 일, 읽은 적대적 콘텐츠에 이끌린 것으로 보이는 일을 막는다. 기본 차단 예: 민감 데이터 외부 전송, 운영 배포, IAM 권한 부여, force push, 실제 자격 증명 출력 | Claude Code 권한 모드 |
| 자동 모드 분류기가 문서 속 지시에 조종당하지 않나 | Claude Code가 직접 보내는 분류기 요청에서는 도구 결과가 빠지므로, 파일· | Claude Code 권한 모드 |
| 조직이 정한 자동 모드 규칙을 개발자가 풀 수 있나 | autoMode 항목은 합쳐진다. 개발자는 environment·allow·soft_deny·hard_deny에 개인 항목을 더할 수 있지만 managed가 준 항목을 지우지는 못한다. 그러나 allow는 분류기 안에서 soft block 규칙의 예외로 작동하므로 개발자가 더한 allow가 조직의 soft_deny를 넘을 수 있다.·.에 둔 autoMode는 분류기가 읽지 않는다. 사용자 의도나 분류기 설정과 상관없이 절대 돌면 안 되는 동작은 managed settings의 permissions.로 막는다 | Claude Code 자동 모드 설정 → Claude Code 자동 모드 설정하기 |
| 서브에이전트가 우회하지 않나 | 자동 모드 분류기는 서브에이전트를 세 지점에서 검사한다. 시작 전에는 위임 내용을 보고 위험해 보이면 시작 시 막고, 실행 중에는 각 동작을 부모 세션과 같은 판정 순서로 보며, 서브에이전트 frontmatter의 permissionMode는 무시한다. 끝난 뒤 검사는 막는 단계가 아니다: 작업이나 보고서에 문제가 보여도 보고서는 보안 경고를 앞에 붙여 전달되고, 분류기를 쓸 수 없으면 작업을 확인하라는 메모를 붙여 전달된다 | Claude Code 권한 모드 |
함께 밝혀야 할 한계(원본 표현 그대로의 강도):
- 자동 모드는 확인 창을 줄이지만 안전을 보장하지 않는다. 민감한 작업의 검토를 대신하는 용도가 아니다. Claude Code 권한 모드
bypassPermissions는 프롬프트 인젝션이나 의도하지 않은 동작에 대한 보호를 주지 않는다. Claude Code 권한 모드- 대화로 말한 "하지 마"는 규칙으로 저장되지 않아 컴팩션으로 사라질 수 있다. 확실한 보장은 deny 규칙이다. Claude Code 권한 모드
- CLAUDE.md 지시는 행동을 이끌 뿐 강제 층이 아니다. 강제는 settings 규칙이 클라이언트에서 한다. Claude Code 메모리 → 메모리(CLAUDE.md)
- 치명 경로 삭제 검사에는 끄는 방법이 있다. Claude Code를 띄우는 환경에서
CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1이면 명령 치환 출력만인 대상의 검사가,CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1이면-c스크립트에 직접 쓴 치명 경로의 검사가 꺼진다. 자동·bypassPermissions모드의 처리(터미널에서 2분 제한 확인 창, 자동 모드의 그 밖 환경에서는 거부)는 v2.1.281 이상이고,CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1이면 자동 모드에서는 치명 경로 삭제가 분류기로 넘어가고bypassPermissions에서는 확인 창에 시간 제한이 없어진다. Claude Code 권한 모드 - 훅의
"allow"는 권한 규칙을 풀지 못한다. settings의 deny 규칙(기업 managed deny 목록 포함)과 ask 규칙은 그대로 적용된다. 반대로PermissionRequest훅은 확인 창에 대신 답하고 세션 모드를 바꿀 수 있으며, matcher를 비우거나.*로 두면 파일 쓰기·셸 명령을 포함한 모든 확인을 자동 승인한다. 편집자 해석: 그래서 누가 user·project 설정에 훅을 넣을 수 있는지도 점검 대상으로 볼 수 있다. 근거는 원본의 "Matching on.*or leaving the matcher empty would auto-approve every tool permission prompt" 문장이다. Claude Code 훅 가이드 - 분류기를 거치지 않는 승인 경로가 있다. 원본: "A mod you install that handles
tool.checkcan approve an action before step 3, and the classifier doesn't check an action the mod approves." 또dontAsk에서도PreToolUse훅이 승인한 호출은 실행된다. 편집자 해석: 그래서 mod·훅을 누가 설치할 수 있는지가 관리자의 통제 지점이 된다. Claude Code 권한 모드 → 훅 (2026-10-21 기준) 공식 권한 문서가 붙이는 조건: mod가--permission-prompt-tool이나 Agent SDK 권한 콜백을 우회할 수 없는 곳에서는 분류기가 먼저 검사한다. managed settings도 Team·Enterprise 로그인도 없는 세션에서는 mod가 deny 거부·훅 차단까지 승인할 수 있고, 있는 세션에서는 그것들이 기본으로 유지된다.dontAsk에서는 mod가 모드만 거부할 호출을 승인할 수 있다. Claude Code 권한 설정
원본끼리 달랐던 점(정리됨)mod 승인이 훅 차단을 넘는 조건
- Claude Code 훅 가이드 (원본 날짜 미상, 수집 2026-10-18): managed settings에 있지 않은 훅이 막은 호출은 mod가 승인할 수 있다("unless the hook is in managed settings").
- Claude Code 권한 설정 (서버 Last-Modified 2026-10-20, 수집 2026-10-21): 기기에 managed settings가 있거나 Team·Enterprise
/login세션이면 "A call that aPreToolUsehook blocked stays blocked, whichever settings file the hook comes from." 둘 다 없으면 mod가 훅 차단·deny 거부를 승인할 수 있다. - 원문 대조와 갈리는 경우는 훅의 같은 콜아웃.
권한 문서 기준으로 해소로 닫는다. 훅 가이드가 같은 문장에서 "Extend permissions with hooks lists which rules hold over a mod"라며 세부 기준을 권한 문서로 넘기고, 권한 문서가 세션 조건("With managed settings on the machine, or a Team or Enterprise /login as the session's credential, these outcomes stay in place by default")을 직접 다루기 때문이다. 고객 제안서에는 권한 문서의 세션 조건으로 쓰고, "관리자가 정한 것은 무엇으로도 못 푼다"로 줄이지 않는다. 위 두 원본 주장과 출처는 그대로 둔다. Claude Code 권한 설정
- PowerShell 삭제: PowerShell 도구를 켠 경우, 시스템 경로(파일 시스템 루트와 그 최상위 디렉터리, 드라이브 루트와 그 최상위 디렉터리, 홈 디렉터리)나 와일드카드(
*,/*·\*로 끝나는 대상)를 겨냥한Remove-Item은 모든 모드에서 묻지 않고 거부한다.cmd로 실행한rd·rmdir·del·erase의 시스템 경로 대상도 기본으로 모든 모드에서 거부한다(v2.1.283 이상). 단 이cmd검사는 Claude Code를 띄우는 환경에서CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1로 끌 수 있다(settings 파일의env블록에 둔 값은 무시). 시스템 경로Remove-Item은 어느 쪽이든 거부된다. 작업 디렉터리나 그 부모를-Recurse로 지우는 경우는 모드의 일반 처리를 따르고bypassPermissions는 이 검사를 건너뛴다. Claude Code 권한 모드 - LLM 게이트웨이·프록시 환경: 자동 모드에서 Claude Code는 분류기 요청 대신 서버에 검토를 맡길 수 있고,
ANTHROPIC_BASE_URL을 LLM 게이트웨이나 프록시로 향하게 한 경우 기본으로 서버에 묻는다(v2.1.278 이상). 게이트웨이·프록시가 검토 요청이나 결과를 떨어뜨리면 Claude Code는 자체 분류기 요청으로 돌아간다. 응답이 검토 결과 전에 끝나거나 결과를 Claude Code가 읽을 수 없는 형태로 바뀌면(게이트웨이·프록시가 응답을 자르거나 결과를 고쳐 쓰는 경우) 그 동작은 검토 없이 실행하지 않고 거부한다.CLAUDE_CODE_AUTO_MODE_SERVER=0이면 서버에 묻지 않고 항상 자체 분류기 요청을 쓴다. Claude Code 권한 모드 - managed settings 자체의 한계: 기기의 로컬 관리자인 개발자는 관리 출처(파일·프로파일)를 고칠 수 있어 MDM 도구가 주기적으로 재배포한다. managed settings는 Claude Code만 묶는다. Anthropic 호스팅 클라우드 세션은 기기 파일·MDM을 읽지 않고, Claude Tag 세션은 서버 관리 설정을 받지 않으며, Cowork 세션은 claude.ai 관리 콘솔 설정을 가져오지 않는다. 정책이 어느 세션에 닿는지부터 확인한다. Claude Code managed settings 배포 → Claude Code managed settings 배포·점검
- 잘못 쓴 정책 중 제한 값이 하나뿐인 키와 일부 허용 목록은 엄격한 쪽으로 읽힌다(fail closed, v2.1.282 이상).
disableAutoMode·allowManagedPermissionRulesOnly같은 제한 키는 읽을 수 없으면 제한 값으로,deny·ask목록을 읽을 수 없으면allow를 보류한다. 열린 쪽으로 가는 경우도 있다: 잘못된disableAllHooks와sandbox.failIfUnavailable은 버려지고, 차단 목록(deniedMcpServers·deniedModels·blockedMarketplaces)이 통째로 잘못되면 경고와 함께 버려지고, 그중deniedModels는 고칠 때까지 어떤 모델도 막지 않으며(원본: "blocks no models until it is fixed"),requiredMinimumVersion·requiredMaximumVersion도 잘못되면 버려진다(fail open). 관리 파일이 있는데 읽히지 않고 정책을 주는 다른 관리자 출처도 없을 때, OS가 읽기를 거부했으면(root 전용 파일 등) 모든 세션이 그 출처의 정책 없이 시작한다. 관리 파일이 JSON으로 파싱되지 않으면 Claude Code가 아예 시작하지 않는다. Claude Code managed settings 배포 → managed settings - Claude Cowork는 Claude Code 모드를 쓰지 않는다. Cowork의 일부 확인 장치는 원본이 "강한 지침"이라 부르는 것이고 기술적 차단이라 말하지 않는다. Claude Code 권한 모드, Claude Cowork 시작하기 → 권한 모드
2. 관리자가 쓰는 설정#
| 목적 | 설정 | 효과 |
|---|---|---|
| 조직의 시작 모드 지정 | managed settings의 permissions. | 터미널 세션이 그 모드로 시작하는 기본값이다. 강제가 아니다: 시작 플래그--permission-mode, --dangerously-skip-permissions)가 settings보다 먼저고, 세션 중 모드 전환도 막지 않아 사람들은 여전히 자동 모드로 바꿀 수 있다. 원본은 자동 모드를 아무도 고를 수 없게 하려면 대신 disableAutoMode를 쓰라고 하고, bypassPermissions는 disable로 막는다. managed·~/.보다 우선한다 |
| 자동 모드 제거 | managed settings 최상위의 "disableAutoMode": "disable"permissions.로도 받는다. 아래 ‘원본끼리 달랐던 점’ 상자) | Shift+Tab 순환에서 빠지고, --permission-mode auto로 시작해도 Manual로 시작한다. settings referencedefault로 시작한다고 적는다. Scope는 Any file이고, managed에 두면 사용자가 덮어쓰지 못한다. 관리자 배포 경로로 설정이 닿으면 실행 중인 자동 모드 세션도 빠져나오며 auto mode disabled by settings를 표시한다 |
bypassPermissions 차단 | managed settings의 permissions. | 이 모드를 막는다. 데스크톱 앱에서 Team·--dangerously-skip-permissions를 거부하고, 서브에이전트 정의의 permissionMode: bypassPermissions를 무시해 부모 세션 모드로 돌린다 |
| 특정 도구· | permissions. 규칙 | 모든 모드에서 막는다. 단 명령Bash(curl *)는 /이나 sh -c 'curl …'을 막지 않는다. Read·Edit deny는 내장 파일 도구, Claude Code가 알아보는 Bash 파일 명령cat·head·tail·sed·tee), 리디렉션 대상에 적용되고, 파일 이름을 대지 않는 grep -r pattern .이나 임의 하위 프로세스에는 적용되지 않는다. 원본은 OS 수준 강제가 필요하면 샌드박스를 켜라고 한다. 규칙 쓰는 법// 절대 경로, Read deny가 같은 경로의 Edit· |
| 사람 확인 지점 두기 | permissions. 규칙Bash(git push *)) | 자동 모드·bypassPermissions에서도 묻는다. dontAsk에서는 거부한다. 명령ask 규칙은 사용자가 "Yes, and don't ask again"으로 local 파일에 저장한 allow보다 앞서고, 커밋한 deny·ask는 팀원의 폴더 신뢰를 기다리지 않고 바로 적용된다 |
| 작업 디렉터리 밖 읽기 차단 | permissions. | 파일 도구가 밖을 읽지 않고, 인식된 파일 읽기 Bash 명령은 자동 모드·bypassPermissions에서도 묻는다true든 적용돼 저장소가 내 설정의 차단을 풀 수 없다. 셸 명령은 파일 도구와 같은 방식으로 거부하지 않고, 샌드박스를 켜면 샌드박스 명령에도 차단이 닿는다 |
| 커넥터 도구 승인 강제 | 조직이 커넥터 도구를 ask로 설정requires | 허용 규칙이 있어도 직접 묻고 분류기로 가지 않는다. dontAsk에서는 거부한다 |
| 관리자 규칙만 인정 | managed settings 최상위의 allow | managed settings만 권한 규칙의 출처가 된다. user·--allowedTools의 규칙을 무시하고, 호스트가 넘긴 허용 규칙도 버린다. settings reference--disallowedTools와 그 세션의 deny·allow가 따로 있다). 프로젝트·allowed-tools도 무시한다 |
| 자동 모드에 신뢰 인프라 알려 주기 | autoMode. | 신뢰하는 저장소·"$defaults"를 넣어야 내장 항목이 남는다. 분류기는 managed settings·~/.·--settings 플래그나 Agent SDK의 인라인 JSON에서만 autoMode를 읽고 저장소 설정 파일에서는 읽지 않는다. 형식과 원본 예시는 Claude Code 자동 모드 설정하기 |
| 일상 패턴 상시 승인 | autoMode. | 막히던 일상 동작을 하나씩 승인하지 않게 한다. 자동 모드 설정 문서allow는 soft_deny의 예외일 뿐 hard_deny는 넘지 못한다. 개발자 개인의 allow도 조직의 soft_deny를 넘을 수 있다는 점은 위 1절 표 |
| 자동 모드 차단 규칙 더하기 | autoMode., autoMode. | 자동 모드 설정 문서soft_deny는 사용자 의도나 allow 예외가 풀 수 있는 파괴적 동작, hard_deny는 사용자 의도·allow가 닿지 않는 무조건 경계다. "$defaults" 없이 두면 그 섹션의 내장 목록 전체가 사라진다soft_deny면 force push·curl | bash·hard_deny면 내장 데이터 유출 규칙). 둘 다 분류기 안의 규칙이고, 분류기보다 먼저 도구 패턴으로 막는 것은 permissions.다 |
| 자동 모드에서 모든 셸 명령을 분류기로 | autoMode. | settings referenceBash(*) 같은 임의 코드 실행 허용 규칙만 정지하고, Bash(npm test)처럼 좁은 허용 규칙에 맞는 명령은 분류기를 건너뛴다true면 자동 모드 동안 셸 허용 규칙을 모두 정지한다. 자동 모드 밖에서는 규칙이 그대로 적용된다. v2.1.193 이상. 자동 모드 설정 문서Monitor를 이름으로 대는 규칙은 정지되고, true일 때도 치명 경로 삭제는 예외이며, 셸 명령마다 분류기 호출 1회로 잡혀 지연이 늘어난다고 덧붙인다 |
| OS 수준 격리 강제 | managed sandbox.와 sandbox., 필요하면 sandbox. | settings referencefailIfUnavailable로 시작을 거부하게 한다. allow는 막힌 명령을 샌드박스 밖에서 다시 돌리는 길을 닫는다excludedCommands에 든 명령은 샌드박스 밖에서 돌고, 원본은 이것을 보안 경계가 아니라고 한다. 격리 대상은 Bash 명령이고 macOS·--settings의 allow, managed allow는 샌드박스를 관리자 필수로 만들어, 저장소의 .·.이 넣은 excludedCommands·allowedDomains·allowWrite 같은 느슨한 설정을 무시한다enabled도 둔다). 그래도 개발자 자신의 ~/.·--settings의 같은 설정은 managed 전용 잠금이 없는 한 적용되고, 개발자가 ! 셸 모드로 직접 친 명령은 대부분의 세션에서 샌드박스 밖에서 돈다enable, enable, network., network., allowAppleEvents)는 원치 않으면 managed에 false로 두고, 자격 증명 디렉터리는 sandbox.로 막는다. failIfUnavailable이 켜지면 Windows 네이티브 기기는 시작 때 종료하므로 macOS· |
근거: Claude Code 권한 모드 (allowManagedPermissionRulesOnly 줄은 Claude Code managed settings 배포와 Claude Code 스킬, ask 줄의 local allow·신뢰 문장은 Claude Code 설정 파일과 우선순위, "권한 문서(2026-10-21)"로 표시한 문장은 Claude Code 권한 설정, "settings reference(2026-10-21)"로 표시한 문장과 마지막 두 줄은 Claude Code 설정 키 전체 레퍼런스, "자동 모드 설정 문서(2026-10-21)"로 표시한 문장은 Claude Code 자동 모드 설정, "샌드박스 문서(2026-10-21)"로 표시한 문장은 Claude Code 샌드박스). 공식 메모리 문서도 도구·명령·경로 차단(permissions.deny), 샌드박스(sandbox.enabled), 로그인 제한은 managed settings에, 행동 지시는 managed CLAUDE.md에 두라고 구분한다. Claude Code 메모리
설정 모양(settings reference 2026-10-21의 각 키 예시 위치를 따라 한 파일에 모은 형태. disableAutoMode는 최상위, 나머지 둘은 permissions 안):
{
"disableAutoMode": "disable",
"permissions": {
"defaultMode": "default",
"disableBypassPermissionsMode": "disable"
}
}원본은 세 키를 각각 따로 설명했고, 이렇게 한 파일에 모은 예시는 원본에 없다. disableAutoMode 예시는 원본 그대로 최상위에 두었다({"disableAutoMode": "disable"}). 원본은 permissions 안에 넣은 permissions.disableAutoMode도 받는다고 적는다. Claude Code 설정 키 전체 레퍼런스
원본끼리 달랐던 점(정리됨)disableAutoMode의 위치 (settings reference 수집, 2026-10-21)
- Claude Code 권한 모드 (원본 날짜 미상, 수집 2026-10-18): "set
permissions.disableAutoModeto"disable"in managed settings"처럼permissions.접두어를 붙여 쓰는 곳이 있다. 같은 문서 안에서도 접두어 없는disableAutoMode표기가 섞인다("Any settings file setsdisableAutoMode", "setdisableAutoModeto"disable"in managed settings"). settings reference 링크 앵커는#disableautomode이고, bypass 잠금 키의 앵커는#permissions-disablebypasspermissionsmode다. - Claude Code managed settings 배포 (원본 날짜 미상, 수집 2026-10-18): 잘못된 값 처리 절에서 "a top-level key that has a single restrictive value, such as
allowManagedPermissionRulesOnly,disableAutoMode, orskipDangerousModePermissionPrompt"라고 최상위 키의 예로 든다. 같은 절은permissions.disableBypassPermissionsMode를 "lock inside"permissions블록의 예로 따로 든다. - 해소 근거 Claude Code 설정 키 전체 레퍼런스 (본문 날짜 없음, 서버 Last-Modified 2026-10-20, 수집 2026-10-21): 키 색인이 최상위 키로 싣는다("|
disableAutoMode| Remove auto mode from the permission mode cycle | Permission settings | Any file |"). 항목의 Scope 줄: "Any file. Most useful in managed settings, where users can't override it. Also accepted underpermissionsaspermissions.disableAutoMode.". 항목 예시는 최상위"disableAutoMode": "disable"이다.permissions객체의 타입도 "object withallow,ask,deny,additionalDirectories,blockReadsOutsideWorkingDirectories,defaultMode,disableBypassPermissionsMode, anddisableAutoMode"라고 적는다. - 결론: 두 원본 모두 틀리지 않았다. 기본 형태는 최상위
"disableAutoMode": "disable"이고,permissions.disableAutoMode도 받는다. 이 위키의 설정 예시는 기본 형태(최상위)로 고쳤다.disableBypassPermissionsMode는permissions안의 키다.
배포 경로·파일 위치·적용 확인은 Claude Code managed settings 배포·점검을 따른다. 공식 배포 문서의 첫 예시는 permissions.deny로 .env·secrets/ 읽기를 막고 permissions.disableBypassPermissionsMode로 bypass 모드를 끄고, 최상위 allowManagedPermissionRulesOnly: true로 user·project·local 파일과 --allowedTools의 권한 규칙을 무시하게 한다. Claude Code managed settings 배포
3. 실행 환경 쪽 안전장치#
| 장치 | 내용 |
|---|---|
--restricted로 시작 | bypassPermissions를 거부하고, 분류기가 보호 경로 쓰기를 승인하지 못한다 |
| root· | Linux·sudo로는 bypassPermissions로 시작하지 않는다. 인식된 샌드박스 안에서는 이 검사를 건너뛴다. 컨테이너 자율 실행은 non-root로 도는 dev container 구성을 쓴다 |
| 클라우드 세션 | 설정 파일의 bypassPermissions·dontAsk를 따르지 않으므로, 저장소에 체크인된 설정이 클라우드 세션을 bypass로 시작시킬 수 없다. 조용히 무시하고 드롭다운의 모드로 시작한다 |
| 최초 수락 대화상자 | bypassPermissions를 켠 첫 대화형 세션은 권한 확인 없이 한 동작에 책임을 진다는 경고를 수락받는다. 거절하면 종료한다. 수락하면 ~/.에 skip가 저장돼 이후 세션은 묻지 않고, 사용자나 조직이 다른 설정 파일에 이 키를 미리 두면 대화상자를 건너뛴다 |
| 반복 차단 시 물러섬 | 연속 3회· |
| 판정 없으면 거부 | 분류기나 서버 측 검토가 판정을 주지 못한 동작은 실행하지 않고 거부한다 |
HIPAA 구성을 적용한 조직: 기본 auto 시작이 적용되지 않아, 다른 설정이 없으면 Manual로 시작한다. 자동 모드와 bypassPermissions는 계속 쓸 수 있으므로 없애려면 managed settings의 disableAutoMode, disableBypassPermissionsMode를 쓴다. v2.1.285 이상. Claude Code 권한 모드
4. 운영과 감사#
- 조직이 배포한 훅만 돌게 하려면 managed
allowManagedHooksOnly를 쓴다. 켜지면/hooks메뉴에 "Only hooks from managed settings run here"가 보이고 user·project·local 설정 파일의 훅은 실행되지 않는다. managed settings의 훅은 managed settings에도disableAllHooks가 있지 않으면 계속 실행된다. Claude Code 훅 가이드 → managed settings- (2026-10-18 기준) 공식 훅 레퍼런스는 범위를 더 넓게 적는다: user·project·local과 플러그인 훅이 막히고, managed
enabledPlugins로 강제 활성화한 플러그인의 훅만 예외다. 함께statusLine·fileSuggestion·subagentStatusLine이 managed 설정으로 좁혀지고,disableCommandPluginSources를 명시적으로false로 두지 않았다면command출처 플러그인과 마켓플레이스headersHelper명령도 막힌다. HTTP 훅 허용 목록(allowedHttpHookUrls,httpHookAllowedEnvVars)은 managed를 포함한 모든 출처의 훅에 적용된다. Claude Code 훅 레퍼런스 - (2026-10-21 기준) settings reference가 더하는 것: Agent SDK가 프로세스 안에서 등록한 훅도 계속 돌고, 다른 플러그인의 mod와 에이전트 frontmatter에 선언한 훅은 막힌다(Claude Code 내장 mod는 계속 돈다). 이 키가 켜져 있으면
/goal명령이 돌지 않는다. 훅 전체를 끄는disableAllHooks는 managed에 두면 managed 훅까지 끄고(Agent SDK 훅은 v2.1.242 이상 유지), 다른 파일에 두면 managed 훅·SDK 훅·강제 활성화 플러그인 훅은 남긴다. Claude Code 설정 키 전체 레퍼런스 - 정책 훅은 기본으로 실패하면 열린다. 스크립트 경로가 틀리거나 죽거나 시간을 넘기면 대부분의 이벤트에서 동작이 진행되므로, 회사 규칙을 맡기는
command·http훅에는"onFailure": "block"(v2.1.295 이상)을 둔다. 원본: "A policy hook with a wrong path or a crashing script then lets everything through." Claude Code 훅 레퍼런스 → Claude Code 차단 훅 단단하게 만들기
- (2026-10-18 기준) 공식 훅 레퍼런스는 범위를 더 넓게 적는다: user·project·local과 플러그인 훅이 막히고, managed
- 설정 변경 기록:
ConfigChange훅은 세션 중 외부 프로세스나 편집기가 설정·스킬 파일을 고칠 때 실행되고, matcher로policy_settings등 출처를 거르며, 종료 코드 2나{"decision": "block"}으로 변경을 막을 수 있다. 원본은 준법 감사용 로그 예를 든다. 팀 전체의 도구 사용 기록에는 HTTP 훅으로 공용 감사 서비스에 보내는 방식을 예로 든다. Claude Code 훅 가이드 → Claude Code 훅 설정 레시피- (2026-10-18 기준) 공식 레퍼런스가 붙이는 조건:
policy_settings변경은 막을 수 없어 기록만 된다(기업 managed 설정이 항상 적용되게). managed 정책은managed-settings.json이나managed-settings.d/의 파일이 바뀔 때만 이 훅을 돌리고, 서버 관리 설정·macOS managed preferences·Windows 레지스트리 정책 변경에는 돌리지 않는다. 막힌 변경은 사용자·Claude에게 메시지 없이 디버그 로그에 한 줄만 남는다. Claude Code 훅 레퍼런스 - 지시 파일 로드 감사에는
InstructionsLoaded훅이 쓰인다. 입력의memory_type(User,Project,Local,Managed)과load_reason으로 어떤 CLAUDE.md·규칙 파일이 왜 로드됐는지 기록할 수 있다. 원본은 용도로 감사 로그·준법 추적을 든다. Claude Code 훅 레퍼런스 → 훅 이벤트 레퍼런스 - 남의 저장소를
claude -p로 돌리는 자동화는 작업 공간 신뢰 대화상자 없이 저장소의.claude/settings.json훅을 실행한다. 원본은 미리 검토하거나--bare, 또는--settings '{"disableAllHooks": true}'를 쓰라고 한다. Claude Code 훅 레퍼런스 (2026-10-21 기준) 공식 권한 문서는--setting-sources user(프로젝트 설정 파일과.mcp.json을 읽지 않음)와disabledMcpjsonServers를 더하고,--bare도 프로젝트env블록과 일부 헬퍼는 막지 못한다고 적는다. Claude Code 권한 설정 → 작업 공간 신뢰
- (2026-10-18 기준) 공식 레퍼런스가 붙이는 조건:
- 자동 모드 분류기가 막은 동작은 알림과 함께
/permissions의 Recently denied 탭에 표시되고, 거기서r로 수동 승인해 다시 시도할 수 있다. 분류기 판정이 없어 거부된 동작은 알림도 이 탭 항목도 없다. 원본은 이 탭을 감사 기록으로 설명하지 않으므로 감사 근거로 내세우지 않는다. Claude Code 권한 모드 - 분류기가 막으면 Claude가 받는 이유는 대부분 일치한 규칙 이름(예:
[Data Exfiltration])이다. Claude Code 권한 모드 claude auto-mode defaults로 기본 규칙 전체를 JSON으로 뽑아 내부 보안 검토 자료로 쓸 수 있다. Claude Code 권한 모드 (2026-10-21 기준)claude auto-mode config는 설정을 적용한 실제 규칙을,claude auto-mode critique는 직접 쓴 항목 중 모호하거나 중복되거나 오탐을 낼 만한 것을 보여 준다.claude auto-mode reset은~/.claude/settings.json의autoMode만 지우고 managed·--settings규칙은 계속 적용된다./permissions의 Auto mode 탭은 managed·--settings에서 온 항목을 읽기 전용으로 보여 주고, 탭에서 바꾼 것은~/.claude/settings.json에 저장한다(v2.1.246 이상). Claude Code 자동 모드 설정- (2026-10-21 기준) Recently denied 탭과 입력창 근처 알림은 명령·URL을 빼고 보여 주므로, 거부된 동작의 정확한 입력을 남기려면
PermissionDenied훅을 더한다(tool_input으로 받는다). Claude Code 자동 모드 설정 → 훅 이벤트 레퍼런스 - 비용: Enterprise 플랜과 Claude API·Claude Platform on AWS·Bedrock·Google Cloud Agent Platform·Microsoft Foundry 계정에서는 분류기 호출이 토큰 사용량에 잡힌다. 읽기와 보호 경로 밖 작업 디렉터리 편집은 분류기를 건너뛰므로 부담은 주로 셸 명령과 네트워크 작업에서 나온다. 서버가 모델 요청의 일부로 검토하면 별도 분류기 호출이 없다. Claude Code 권한 모드
- 자동 모드 분류기는 기본으로 사용자의
/model선택과 별개인 Claude Sonnet 5에서 돈다. Claude Code 권한 모드
5. 구성 조합 예 (편집자 해석)#
편집자 해석: 위 설정을 위험 수준별로 묶으면 다음처럼 볼 수 있다. 원본은 이런 등급표를 제시하지 않는다. 근거 문장은 각 줄에 짚었다.
- 민감 업무 중심 조직: managed settings에서
bypassPermissions를 막고(원본: "Administrators can block this mode"), 시작 기본값을 Manual로 두고(원본 "Sensitive work"용 모드. 다만 manageddefaultMode는 기본값일 뿐이라 시작 플래그가 우선하고 세션 중 자동 모드 전환도 막지 않으므로, 자동 모드까지 없애려면disableAutoMode를 함께 쓴다), 외부 전송·push 같은 명령에 deny나 ask 규칙을 거는 조합을 생각할 수 있다(원본: deny 규칙은 모든 모드에서 막고, ask 규칙은 자동 모드에서도 묻는다. 두 규칙 모두 명령은 쓰인 그대로 맞춘다). - 확인 창 피로가 큰 개발 조직: 자동 모드를 켜 두고
autoMode.environment에 신뢰 인프라를 등록하는 조합을 생각할 수 있다(원본: 반복 차단은 대개 분류기가 인프라 맥락을 모른다는 뜻이고, 관리자가 신뢰 인프라를 설정할 수 있다). 자동 모드 설정 문서(2026-10-21)가 제시한 도입 순서는 기본값에서 시작해 소스 관리 조직과 핵심 내부 서비스, 다음에 신뢰 도메인과 버킷, 나머지는 차단이 생길 때마다다. 다만 그 문서는 조직soft_deny를 개발자allow가 넘을 수 있다고 하므로, 절대 막을 동작은 같은 managed settings의permissions.deny에 따로 둔다. - CI·자동화:
dontAsk와 정확한--allowedTools목록(원본 "Locked-down CI and scripts"), 완전 무인 실행은 컨테이너·VM 안에서만(원본 "Isolated containers and VMs only").
됐는지 확인하는 법#
이 페이지의 원본들은 "통제 전체가 걸렸는지"를 한 번에 확인하는 방법을 따로 주지 않는다. 설정마다 원본이 적은 확인 방법은 다음과 같다.
- 관리 출처가 적용됐는지: 기기에서
/status의Setting sources줄에Enterprise managed settings (...)가 보이는지 본다. 세부 판독은 Claude Code managed settings 배포·점검의 "됐는지 확인하는 법". Claude Code managed settings 배포 - 자동 모드를 없앴는지 (
disableAutoMode): 자동 모드가Shift+Tab순환에서 빠지고,--permission-mode auto로 시작해도 Manual로 시작한다. 실행 중인 자동 모드 세션은auto mode disabled by settings를 표시하며 빠져나온다(v2.1.251 이상, 관리자 배포 경로로 닿았을 때)(2절 표). Claude Code 권한 모드 - 관리자 훅만 돌게 했는지 (
allowManagedHooksOnly):/hooks메뉴에 "Only hooks from managed settings run here"가 보인다(4절). Claude Code 훅 가이드 - 자동 모드 규칙이 어떻게 합쳐졌는지:
claude auto-mode config가 설정을 적용한 실제 규칙을 보여 주고,/permissions의 Auto mode 탭은 managed·--settings에서 온 항목을 읽기 전용으로 보여 준다(v2.1.246 이상)(4절). Claude Code 자동 모드 설정 - 무엇이 막혔는지: 자동 모드 분류기가 막은 동작은
/permissions의 Recently denied 탭에 남는다. 다만 판정이 없어 거부된 동작은 이 탭에 남지 않고, 원본은 이 탭을 감사 기록으로 설명하지 않는다(4절). Claude Code 권한 모드
언제 쓰고 언제 쓰지 않는가#
- 쓴다: 금융·공공 고객의 보안 검토 질문에 답할 때, AX 컨설팅에서 Claude Code 도입 정책을 설계할 때, 사내 배포 전 관리자 체크리스트를 만들 때.
- 쓰지 않는다: 개인이 자기 세션의 모드를 고르는 일이면 Claude Code 권한 모드 고르기. Claude Cowork 정책은 Cowork 자체 권한 모드를 따로 확인한다(이 위키에는 아직 공식 문서가 없다). Claude Code 권한 모드
- 배포·확인 절차는 Claude Code managed settings 배포·점검, 우선순위·출처 합치기는 managed settings.
- 주의: 대외 자료에 숫자·버전·키 이름을 넣기 전에 공식 문서로 다시 확인한다. 위 표는 2026-10-18 수집본 기준이고, "settings reference(2026-10-21)"·"권한 문서(2026-10-21)"·"자동 모드 설정 문서(2026-10-21)"·"샌드박스 문서(2026-10-21)"로 표시하거나 "(2026-10-21 기준)"을 붙인 문장만 2026-10-21 수집본 기준이다.