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 *)"
]
}
}
중요한 점은 규칙을 넓게 만들지 않는 것이다. Bash나 Bash(*)를 통째로 허용하면 승인 프롬프트는 줄어들지만, 임의의 셸 명령까지 허용하는 셈이 된다. 반복해서 쓰는 명령을 정확히 적고, 배포, 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처럼 호스트 시스템에 피해를 주기 어려운 격리 환경에서만 쓰라고 설명한다. 일반 로컬 프로젝트에서 편의성 때문에 기본값으로 두는 것은 권장하기 어렵다.
추천 조합
대부분의 개발 작업에서는 다음 조합이 가장 현실적이다.
- 평소에는
acceptEdits로 시작한다. - 반복되는 빌드, 테스트, 포맷 명령만
permissions.allow에 추가한다. - push, 배포, 삭제, 권한 변경은
deny나 수동 승인으로 남긴다. - 긴 작업에서만
auto를 검토한다. bypassPermissions는 격리된 실험 환경에서만 사용한다.
이렇게 설정하면 승인 피로는 줄이면서도, Claude Code가 프로젝트 밖이나 운영 환경에 영향을 주는 작업을 마음대로 실행할 가능성은 낮출 수 있다.
확인한 문서

Claude Code asks for permission before actions that can affect your environment, such as editing files, running shell commands, or making network requests. That approval step is a safety guard, but it can interrupt the flow during repetitive development work.
As of May 29, 2026, the official docs point to three practical options to consider first. Instead of turning off every approval prompt, it is better to narrow the permission scope to match the risk of the task.
Quick Decision Guide
| Method | Best for | Watch out for |
|---|---|---|
acceptEdits |
Letting Claude edit files automatically while still reviewing sensitive commands | Paths outside the working directory, protected paths, and most Bash commands still require approval. |
permissions.allow |
Running specific repeated commands without approval | Avoid broad rules like Bash(*); allow only the commands you actually need. |
auto |
Reducing prompt fatigue during longer tasks | It is a research preview and requires the right account, model, and provider conditions. |
1. Start with acceptEdits for Everyday Development
The most balanced option is acceptEdits mode. It lets Claude create and edit files inside your working directory without asking each time. Common filesystem commands such as mkdir, touch, mv, cp, and sed are also auto-approved when they stay in scope.
claude --permission-mode acceptEdits
If Claude Code is already running, press Shift+Tab to switch modes. From the default mode, pressing it once enters acceptEdits.
This mode fits the workflow: “Claude can make the code changes, and I will review them afterward with git diff.” Commands with wider impact, such as package installation, deployment, writing outside the project, or editing protected paths, still require confirmation.
To make it the default, add this to your settings file.
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
2. Allow Repeated Commands with Narrow Permission Rules
If you keep approving the same command, a permission rule is more precise. You can inspect and manage current rules with /permissions, and you can also define allow, ask, and deny rules in user or project settings.
For example, if you want to allow build and test commands but block direct pushes, use a configuration like this.
{
"permissions": {
"allow": [
"Bash(npm run build)",
"Bash(npm run test *)"
],
"deny": [
"Bash(git push *)"
]
}
}
The important part is to keep rules narrow. Allowing Bash or Bash(*) removes a lot of prompts, but it also allows arbitrary shell commands. Write exact rules for commands you repeat often, and keep deployment, push, deletion, and permission-changing operations behind deny rules or manual approval.
3. Consider auto for Longer Runs
auto mode lets Claude use tools without asking every time, while a separate safety classifier checks whether each action stays within your request. The documented CLI form is:
claude --permission-mode auto
The old command --enable-auto-mode from this article’s previous version is not the documented CLI option. Use --permission-mode auto instead.
Still, auto is not a mode for handing over any task blindly. It is a research preview, and it depends on Claude Code version, account settings, model support, and provider support. Team or Enterprise workspaces may also require an administrator to enable it first. The classifier may block deployments, migrations, permission grants, mass deletion, force pushes, and similar high-impact actions.
Use auto when the goal and boundaries are clear, such as “refactor this component until tests pass.” For deployment or data deletion, keep a separate human approval step.
Do Not Treat bypassPermissions as a Normal Default
There is also a way to turn off all prompts.
claude --permission-mode bypassPermissions
The equivalent flag is:
claude --dangerously-skip-permissions
This mode bypasses the permission layer itself. The official docs describe it as appropriate only in isolated environments such as containers, VMs, or dev containers without internet access, where Claude Code cannot damage the host system. It should not be your default setting for ordinary local projects.
Recommended Setup
For most development work, this combination is the most practical:
- Start in
acceptEdits. - Add only repeated build, test, and format commands to
permissions.allow. - Leave push, deployment, deletion, and permission changes behind
denyrules or manual approval. - Consider
autoonly for long-running tasks with clear boundaries. - Use
bypassPermissionsonly in isolated experiment environments.
This reduces approval fatigue while keeping Claude Code from freely affecting files outside the project or sensitive operational environments.
Sources Checked

Claude Code 在执行会影响工作环境的操作之前会请求权限,例如修改文件、运行 shell 命令或发起网络请求。这个确认步骤是安全保护,但在重复性的开发工作中也会打断流程。
截至 2026 年 5 月 29 日,官方文档中最值得先考虑的实用选择主要有三种。与其直接关闭所有审批提示,不如根据任务风险缩小权限范围。
快速选择指南
| 方法 | 适合场景 | 注意点 |
|---|---|---|
acceptEdits |
让 Claude 自动修改文件,同时继续确认敏感命令 | 工作目录之外、受保护路径以及大多数 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 规则。
例如,如果想允许 build 和 test 命令,但阻止直接 push,可以这样写。
{
"permissions": {
"allow": [
"Bash(npm run build)",
"Bash(npm run test *)"
],
"deny": [
"Bash(git push *)"
]
}
}
关键是不要把规则写得太宽。允许 Bash 或 Bash(*) 虽然能减少很多提示,但也等于允许任意 shell 命令。对于经常重复的命令写精确规则,而部署、push、删除、权限变更这类难以回滚的操作最好保留为 deny 或手动审批。
3. 长时间任务可以考虑 auto
auto 模式让 Claude 使用工具时不再每次询问,同时由单独的安全分类器检查每个动作是否仍在你的请求范围内。官方文档中的 CLI 写法是:
claude --permission-mode auto
旧版文章里提到的 --enable-auto-mode 不是官方文档中的 CLI 选项。当前应使用 --permission-mode auto。
不过,auto 并不是可以盲目交给 Claude 处理任何任务的模式。它是研究预览功能,并依赖 Claude Code 版本、账户设置、模型支持和服务提供方支持。在 Team 或 Enterprise 环境中,管理员可能还需要先启用它。分类器也可能会阻止部署、迁移、授予权限、大量删除、强制 push 等高影响操作。
当目标和边界清楚时,auto 更合适。例如“重构这个组件直到测试通过”。对于部署或数据删除,最好保留单独的人为确认步骤。
不要把 bypassPermissions 当作普通默认值
也有完全关闭所有提示的方法。
claude --permission-mode bypassPermissions
等价的 flag 是:
claude --dangerously-skip-permissions
但这个模式会绕过权限层本身。官方文档将它定位为只适合容器、VM、无互联网访问的 dev container 等隔离环境,在这些环境中 Claude Code 不容易伤害宿主系统。它不应该成为普通本地项目的默认设置。
推荐组合
对大多数开发工作来说,下面的组合最现实:
- 平时从
acceptEdits开始。 - 只把重复的 build、test、format 命令加入
permissions.allow。 - push、部署、删除、权限变更保留为
deny或手动审批。 - 只有在边界明确的长任务中才考虑
auto。 - 只在隔离实验环境中使用
bypassPermissions。
这样既能减少审批疲劳,也能降低 Claude Code 随意影响项目外文件或敏感运行环境的可能性。
已核对文档

Claude Code は、ファイル編集、シェルコマンドの実行、ネットワークリクエストなど、作業環境に影響する操作の前に権限確認を求める。この確認は安全装置だが、反復的な開発作業では流れを止めてしまうこともある。
2026年5月29日時点で公式ドキュメントを確認すると、実務でまず検討したい選択肢は主に3つある。すべての確認を無条件に消すのではなく、作業のリスクに合わせて権限範囲を絞る方がよい。
すばやい選び方
| 方法 | 向いている状況 | 注意点 |
|---|---|---|
acceptEdits |
ファイル編集は自動化しつつ、重要なコマンドは確認したい場合 | 作業ディレクトリ外、保護されたパス、多くの Bash コマンドは引き続き承認が必要。 |
permissions.allow |
繰り返し使う特定コマンドだけを承認なしで実行したい場合 | Bash(*) のような広すぎるルールは避け、必要なコマンドだけを許可する。 |
auto |
長い作業で承認疲れを減らしたい場合 | 研究プレビューであり、アカウント、モデル、プロバイダーの条件を満たす必要がある。 |
1. 通常の開発は acceptEdits から始める
最も扱いやすい選択肢は acceptEdits モードだ。このモードでは、Claude が作業ディレクトリ内のファイル作成や編集を確認なしで進められる。mkdir、touch、mv、cp、sed などの一般的なファイルシステムコマンドも、範囲内であれば自動承認される。
claude --permission-mode acceptEdits
すでに Claude Code を起動している場合は、Shift+Tab でモードを切り替えられる。default mode から1回押すと acceptEdits に入る。
このモードは「Claude にコードを変更させ、あとで git diff で確認する」という作業スタイルに合っている。一方で、パッケージのインストール、デプロイ、プロジェクト外への書き込み、保護されたパスの変更など、影響範囲が大きい操作は引き続き確認を求める。
デフォルトにしたい場合は、設定ファイルに次のように書ける。
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
2. 反復コマンドは狭い permission rule で許可する
毎回同じコマンドを承認しているなら、permission rule を使う方が正確だ。/permissions で現在のルールを確認、管理でき、ユーザー設定やプロジェクト設定にも allow、ask、deny ルールを書ける。
たとえば build と test は許可し、直接 push は止めたいなら次のように設定する。
{
"permissions": {
"allow": [
"Bash(npm run build)",
"Bash(npm run test *)"
],
"deny": [
"Bash(git push *)"
]
}
}
重要なのは、ルールを広げすぎないことだ。Bash や Bash(*) を丸ごと許可すればプロンプトは減るが、任意のシェルコマンドまで許可することになる。頻繁に繰り返すコマンドだけを正確に書き、デプロイ、push、削除、権限変更のように戻しにくい操作は deny か手動承認に残しておくのが安全だ。
3. 長時間の作業では auto を検討する
auto モードでは、Claude がツールを使うたびにユーザーへ確認せず、別の安全性分類器が各操作が依頼範囲内かどうかを確認する。公式ドキュメント上の CLI は次の形だ。
claude --permission-mode auto
この記事の以前の版にあった --enable-auto-mode は、公式 CLI オプションとして確認できない。現在のドキュメント基準では --permission-mode auto を使う。
ただし、auto はどんな作業でも安全に任せられるモードではない。研究プレビューであり、Claude Code のバージョン、アカウント設定、モデル、プロバイダーの条件を満たす必要がある。Team や Enterprise 環境では、管理者による有効化が必要な場合もある。また分類器は、デプロイ、マイグレーション、権限付与、大量削除、force push などの影響が大きい操作をブロックすることがある。
そのため auto は、目標と境界が明確な長い作業に向いている。たとえば「テストが通るまでこのコンポーネントをリファクタリングして」のようなケースだ。デプロイやデータ削除では、人間の確認ステップを別に残した方がよい。
bypassPermissions を通常のデフォルトにしない
すべてのプロンプトを消す方法もある。
claude --permission-mode bypassPermissions
同じ意味の flag もある。
claude --dangerously-skip-permissions
ただし、このモードは permission layer 自体を迂回する。公式ドキュメントでも、コンテナ、VM、インターネット接続のない dev container など、ホストシステムに被害を与えにくい隔離環境でのみ使うものとして説明されている。通常のローカルプロジェクトのデフォルトにするのは避けたい。
おすすめの組み合わせ
多くの開発作業では、次の組み合わせが現実的だ。
- 普段は
acceptEditsで始める。 - 繰り返す build、test、format コマンドだけを
permissions.allowに追加する。 - push、デプロイ、削除、権限変更は
denyまたは手動承認に残す。 - 境界が明確な長時間タスクだけで
autoを検討する。 bypassPermissionsは隔離された実験環境でのみ使う。
この設定なら承認疲れを減らしつつ、Claude Code がプロジェクト外のファイルや重要な運用環境に自由に影響を与える可能性を下げられる。
確認したドキュメント

Claude Code pide permiso antes de ejecutar acciones que pueden afectar tu entorno, como editar archivos, ejecutar comandos de shell o hacer solicitudes de red. Ese paso funciona como una protección, pero también puede romper el flujo durante trabajos de desarrollo repetitivos.
A fecha del 29 de mayo de 2026, la documentación oficial apunta a tres opciones prácticas para revisar primero. En vez de desactivar todas las aprobaciones, conviene ajustar el alcance de permisos al riesgo de cada tarea.
Guía Rápida de Elección
| Método | Cuándo usarlo | Precaución |
|---|---|---|
acceptEdits |
Para dejar que Claude edite archivos automáticamente mientras sigues revisando comandos sensibles | Las rutas fuera del directorio de trabajo, las rutas protegidas y la mayoría de comandos Bash todavía requieren aprobación. |
permissions.allow |
Para ejecutar comandos repetidos concretos sin aprobación | Evita reglas amplias como Bash(*); permite solo los comandos necesarios. |
auto |
Para reducir la fatiga de aprobación en tareas largas | Es una vista previa de investigación y requiere condiciones de cuenta, modelo y proveedor. |
1. Empieza con acceptEdits para Desarrollo Diario
La opción más equilibrada es el modo acceptEdits. Permite que Claude cree y edite archivos dentro del directorio de trabajo sin pedir confirmación cada vez. Comandos comunes del sistema de archivos como mkdir, touch, mv, cp y sed también se aprueban automáticamente cuando se mantienen dentro del alcance permitido.
claude --permission-mode acceptEdits
Si Claude Code ya está ejecutándose, puedes cambiar de modo con Shift+Tab. Desde el modo predeterminado, al presionarlo una vez entras en acceptEdits.
Este modo encaja con el flujo: “Claude puede hacer los cambios y yo los reviso después con git diff”. Las operaciones con mayor impacto, como instalar paquetes, desplegar, escribir fuera del proyecto o editar rutas protegidas, siguen requiriendo confirmación.
Para usarlo como valor predeterminado, añade esto al archivo de configuración.
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
2. Permite Comandos Repetidos con Reglas de Permiso Concretas
Si apruebas el mismo comando una y otra vez, una regla de permisos es más precisa. Puedes inspeccionar y gestionar las reglas actuales con /permissions, y también definir reglas allow, ask y deny en la configuración de usuario o proyecto.
Por ejemplo, si quieres permitir comandos de build y test, pero bloquear push directos, usa una configuración como esta.
{
"permissions": {
"allow": [
"Bash(npm run build)",
"Bash(npm run test *)"
],
"deny": [
"Bash(git push *)"
]
}
}
Lo importante es mantener las reglas estrechas. Permitir Bash o Bash(*) reduce muchas solicitudes, pero también permite comandos de shell arbitrarios. Escribe reglas exactas para comandos que repites a menudo y deja despliegues, push, borrados y cambios de permisos detrás de reglas deny o aprobación manual.
3. Considera auto para Tareas Largas
El modo auto permite que Claude use herramientas sin preguntar cada vez, mientras un clasificador de seguridad separado comprueba si cada acción se mantiene dentro de tu solicitud. La forma documentada en CLI es:
claude --permission-mode auto
El comando antiguo --enable-auto-mode de la versión previa de este artículo no es la opción CLI documentada. Usa --permission-mode auto.
Aun así, auto no es un modo para delegar cualquier tarea a ciegas. Es una vista previa de investigación y depende de la versión de Claude Code, la configuración de la cuenta, el soporte del modelo y el soporte del proveedor. En espacios Team o Enterprise, puede que un administrador tenga que habilitarlo primero. El clasificador también puede bloquear despliegues, migraciones, concesiones de permisos, borrados masivos, force push y acciones similares de alto impacto.
Usa auto cuando el objetivo y los límites estén claros, por ejemplo: “refactoriza este componente hasta que pasen los tests”. Para despliegues o borrado de datos, conserva un paso separado de aprobación humana.
No Trates bypassPermissions como un Valor Predeterminado Normal
También existe una forma de desactivar todas las solicitudes.
claude --permission-mode bypassPermissions
El flag equivalente es:
claude --dangerously-skip-permissions
Este modo evita la capa de permisos. La documentación oficial lo describe como adecuado solo para entornos aislados, como contenedores, VM o dev containers sin acceso a internet, donde Claude Code no pueda dañar el sistema anfitrión. No debería ser tu configuración predeterminada para proyectos locales normales.
Configuración Recomendada
Para la mayoría del trabajo de desarrollo, esta combinación es la más práctica:
- Empieza en
acceptEdits. - Añade solo comandos repetidos de build, test y formato a
permissions.allow. - Deja push, despliegues, borrados y cambios de permisos detrás de
denyo aprobación manual. - Considera
autosolo para tareas largas con límites claros. - Usa
bypassPermissionssolo en entornos experimentales aislados.
Así reduces la fatiga de aprobación sin dejar que Claude Code afecte libremente archivos fuera del proyecto o entornos operativos sensibles.