Konfigurasi izin - Claude Code Docs

Claude Code mendukung izin terperinci sehingga Anda dapat menentukan dengan tepat apa yang diizinkan dilakukan oleh agen dan apa yang tidak. Pengaturan izin dapat diperiksa ke dalam kontrol versi dan didistribusikan ke semua pengembang di organisasi Anda, serta disesuaikan oleh pengembang individual.

Sistem izin

Claude Code menggunakan sistem izin berjenjang untuk menyeimbangkan kekuatan dan keamanan:

Jenis alat	Contoh	Persetujuan diperlukan	Perilaku “Ya, jangan tanya lagi”
Hanya baca	Pembacaan file, Grep	Tidak	T/A
Perintah Bash	Eksekusi shell	Ya	Secara permanen per direktori proyek dan perintah
Modifikasi file	Edit/tulis file	Ya	Hingga akhir sesi

Kelola izin

Anda dapat melihat dan mengelola izin alat Claude Code dengan /permissions. UI ini mencantumkan semua aturan izin dan file settings.json tempat mereka bersumber.

Aturan Allow memungkinkan Claude Code menggunakan alat yang ditentukan tanpa persetujuan manual.
Aturan Ask meminta konfirmasi setiap kali Claude Code mencoba menggunakan alat yang ditentukan.
Aturan Deny mencegah Claude Code menggunakan alat yang ditentukan.

Aturan dievaluasi secara berurutan: deny -> ask -> allow. Aturan pertama yang cocok menang, jadi aturan deny selalu memiliki prioritas.

Mode izin

Claude Code mendukung beberapa mode izin yang mengontrol bagaimana alat disetujui. Lihat Mode izin untuk mengetahui kapan menggunakan masing-masing. Atur defaultMode dalam file pengaturan Anda:

Mode	Deskripsi
`default`	Perilaku standar: meminta izin pada penggunaan pertama setiap alat
`acceptEdits`	Secara otomatis menerima izin edit file untuk sesi
`plan`	Plan Mode: Claude dapat menganalisis tetapi tidak memodifikasi file atau menjalankan perintah
`auto`	Secara otomatis menyetujui panggilan alat dengan pemeriksaan keamanan latar belakang yang memverifikasi tindakan selaras dengan permintaan Anda. Saat ini pratinjau penelitian
`dontAsk`	Secara otomatis menolak alat kecuali pra-disetujui melalui `/permissions` atau aturan `permissions.allow`
`bypassPermissions`	Melewati prompt izin kecuali untuk penulisan ke direktori yang dilindungi (lihat peringatan di bawah)

Mode bypassPermissions melewati prompt izin. Penulisan ke direktori .git, .claude, .vscode, dan .idea masih meminta konfirmasi untuk mencegah kerusakan tidak disengaja pada status repositori dan konfigurasi lokal. Penulisan ke .claude/commands, .claude/agents, dan .claude/skills dikecualikan dan tidak meminta, karena Claude secara rutin menulis di sana saat membuat skills, subagents, dan commands. Hanya gunakan mode ini di lingkungan terisolasi seperti kontainer atau VM tempat Claude Code tidak dapat menyebabkan kerusakan. Administrator dapat mencegah mode ini dengan mengatur disableBypassPermissionsMode ke "disable" dalam pengaturan terkelola.

Untuk mencegah bypassPermissions atau mode auto digunakan, atur permissions.disableBypassPermissionsMode atau disableAutoMode ke "disable" dalam file pengaturan apa pun. Ini paling berguna dalam pengaturan terkelola di mana mereka tidak dapat ditimpa.

Sintaks aturan izin

Aturan izin mengikuti format Tool atau Tool(specifier).

Cocokkan semua penggunaan alat

Untuk mencocokkan semua penggunaan alat, gunakan hanya nama alat tanpa tanda kurung:

Aturan	Efek
`Bash`	Mencocokkan semua perintah Bash
`WebFetch`	Mencocokkan semua permintaan pengambilan web
`Read`	Mencocokkan semua pembacaan file

Bash(*) setara dengan Bash dan mencocokkan semua perintah Bash.

Gunakan specifier untuk kontrol terperinci

Tambahkan specifier dalam tanda kurung untuk mencocokkan penggunaan alat tertentu:

Aturan	Efek
`Bash(npm run build)`	Mencocokkan perintah yang tepat `npm run build`
`Read(./.env)`	Mencocokkan pembacaan file `.env` di direktori saat ini
`WebFetch(domain:example.com)`	Mencocokkan permintaan pengambilan ke example.com

Pola wildcard

Aturan Bash mendukung pola glob dengan *. Wildcard dapat muncul di posisi mana pun dalam perintah. Konfigurasi ini memungkinkan perintah npm dan git commit sambil memblokir git push:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Spasi sebelum * penting: Bash(ls *) mencocokkan ls -la tetapi bukan lsof, sementara Bash(ls*) mencocokkan keduanya. Sintaks akhiran :* warisan setara dengan * tetapi sudah usang.

Aturan izin khusus alat

Bash

Aturan izin Bash mendukung pencocokan wildcard dengan *. Wildcard dapat muncul di posisi mana pun dalam perintah, termasuk di awal, tengah, atau akhir:

Bash(npm run build) mencocokkan perintah Bash yang tepat npm run build
Bash(npm run test *) mencocokkan perintah Bash yang dimulai dengan npm run test
Bash(npm *) mencocokkan perintah apa pun yang dimulai dengan npm
Bash(* install) mencocokkan perintah apa pun yang berakhir dengan install
Bash(git * main) mencocokkan perintah seperti git checkout main, git merge main

Ketika * muncul di akhir dengan spasi sebelumnya (seperti Bash(ls *)), ini memberlakukan batas kata, memerlukan awalan diikuti oleh spasi atau akhir string. Misalnya, Bash(ls *) mencocokkan ls -la tetapi bukan lsof. Sebaliknya, Bash(ls*) tanpa spasi mencocokkan ls -la dan lsof karena tidak ada batasan batas kata.

Claude Code menyadari operator shell (seperti &&) jadi aturan pencocokan awalan seperti Bash(safe-cmd *) tidak akan memberinya izin untuk menjalankan perintah safe-cmd && other-cmd.

Ketika Anda menyetujui perintah gabungan dengan “Ya, jangan tanya lagi”, Claude Code menyimpan aturan terpisah untuk setiap subperintah yang memerlukan persetujuan, bukan satu aturan untuk string gabungan lengkap. Misalnya, menyetujui git status && npm test menyimpan aturan untuk npm test, jadi invokasi npm test di masa depan dikenali terlepas dari apa yang mendahului &&. Subperintah seperti cd ke subdirektori menghasilkan aturan Read mereka sendiri untuk jalur itu. Hingga 5 aturan dapat disimpan untuk satu perintah gabungan.

Pola izin Bash yang mencoba membatasi argumen perintah rapuh. Misalnya, Bash(curl http://github.com/ *) dimaksudkan untuk membatasi curl ke URL GitHub, tetapi tidak akan mencocokkan variasi seperti:

Opsi sebelum URL: curl -X GET http://github.com/...
Protokol berbeda: curl https://github.com/...
Pengalihan: curl -L http://bit.ly/xyz (pengalihan ke github)
Variabel: URL=http://github.com && curl $URL
Spasi ekstra: curl http://github.com

Untuk penyaringan URL yang lebih andal, pertimbangkan:

Batasi alat jaringan Bash: gunakan aturan deny untuk memblokir curl, wget, dan perintah serupa, kemudian gunakan alat WebFetch dengan izin WebFetch(domain:github.com) untuk domain yang diizinkan
Gunakan hook PreToolUse: implementasikan hook yang memvalidasi URL dalam perintah Bash dan memblokir domain yang tidak diizinkan
Menginstruksikan Claude Code tentang pola curl yang diizinkan Anda melalui CLAUDE.md

Perhatikan bahwa menggunakan WebFetch saja tidak mencegah akses jaringan. Jika Bash diizinkan, Claude masih dapat menggunakan curl, wget, atau alat lain untuk menjangkau URL apa pun.

Read dan Edit

Aturan Edit berlaku untuk semua alat bawaan yang mengedit file. Claude membuat upaya terbaik untuk menerapkan aturan Read ke semua alat bawaan yang membaca file seperti Grep dan Glob.

Aturan deny Read dan Edit berlaku untuk alat file bawaan Claude, bukan untuk subproses Bash. Aturan deny Read(./.env) memblokir alat Read tetapi tidak mencegah cat .env di Bash. Untuk penegakan tingkat OS yang memblokir semua proses dari mengakses jalur, aktifkan sandbox.

Aturan Read dan Edit keduanya mengikuti spesifikasi gitignore dengan empat jenis pola yang berbeda:

Pola	Arti	Contoh	Cocok
`//path`	Jalur absolut dari akar sistem file	`Read(//Users/alice/secrets/**)`	`/Users/alice/secrets/**`
`~/path`	Jalur dari direktori home	`Read(~/Documents/*.pdf)`	`/Users/alice/Documents/*.pdf`
`/path`	Jalur relatif terhadap akar proyek	`Edit(/src/*/.ts)`	`<project root>/src/*/.ts`
`path` atau `./path`	Jalur relatif terhadap direktori saat ini	`Read(*.env)`	`<cwd>/*.env`

Pola seperti /Users/alice/file BUKAN jalur absolut. Ini relatif terhadap akar proyek. Gunakan //Users/alice/file untuk jalur absolut.

Di Windows, jalur dinormalisasi ke bentuk POSIX sebelum pencocokan. C:\Users\alice menjadi /c/Users/alice, jadi gunakan //c/**/.env untuk mencocokkan file .env di mana pun di drive itu. Untuk mencocokkan di semua drive, gunakan //**/.env. Contoh:

Edit(/docs/**): edit di <project>/docs/ (BUKAN /docs/ dan BUKAN <project>/.claude/docs/)
Read(~/.zshrc): membaca .zshrc direktori home Anda
Edit(//tmp/scratch.txt): edit jalur absolut /tmp/scratch.txt
Read(src/**): membaca dari <current-directory>/src/

Dalam pola gitignore, * mencocokkan file dalam satu direktori sementara ** mencocokkan secara rekursif di seluruh direktori. Untuk memungkinkan semua akses file, gunakan hanya nama alat tanpa tanda kurung: Read, Edit, atau Write.

WebFetch

WebFetch(domain:example.com) mencocokkan permintaan pengambilan ke example.com

MCP

mcp__puppeteer mencocokkan alat apa pun yang disediakan oleh server puppeteer (nama dikonfigurasi di Claude Code)
mcp__puppeteer__* sintaks wildcard yang juga mencocokkan semua alat dari server puppeteer
mcp__puppeteer__puppeteer_navigate mencocokkan alat puppeteer_navigate yang disediakan oleh server puppeteer

Agent (subagents)

Gunakan aturan Agent(AgentName) untuk mengontrol subagents mana yang dapat digunakan Claude:

Agent(Explore) mencocokkan subagent Explore
Agent(Plan) mencocokkan subagent Plan
Agent(my-custom-agent) mencocokkan subagent kustom bernama my-custom-agent

Tambahkan aturan ini ke array deny dalam pengaturan Anda atau gunakan flag CLI --disallowedTools untuk menonaktifkan agen tertentu. Untuk menonaktifkan agen Explore:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Perluas izin dengan hook

Hook Claude Code menyediakan cara untuk mendaftarkan perintah shell kustom guna melakukan evaluasi izin saat runtime. Ketika Claude Code membuat panggilan alat, hook PreToolUse berjalan sebelum prompt izin. Output hook dapat menolak panggilan alat, memaksa prompt, atau melewati prompt untuk membiarkan panggilan berlanjut. Melewati prompt tidak melewati aturan izin. Aturan deny dan ask masih dievaluasi setelah hook mengembalikan "allow", jadi aturan deny yang cocok masih memblokir panggilan. Ini mempertahankan prioritas deny-first yang dijelaskan dalam Kelola izin, termasuk aturan deny yang ditetapkan dalam pengaturan terkelola. Hook pemblokiran juga memiliki prioritas atas aturan allow. Hook yang keluar dengan kode 2 menghentikan panggilan alat sebelum aturan izin dievaluasi, jadi blokir berlaku bahkan ketika aturan allow akan membiarkan panggilan berlanjut. Untuk menjalankan semua perintah Bash tanpa prompt kecuali untuk beberapa yang ingin Anda blokir, tambahkan "Bash" ke daftar allow Anda dan daftarkan hook PreToolUse yang menolak perintah tertentu itu. Lihat Blokir edit ke file yang dilindungi untuk skrip hook yang dapat Anda sesuaikan.

Direktori kerja

Secara default, Claude memiliki akses ke file di direktori tempat diluncurkan. Anda dapat memperluas akses ini:

Saat startup: gunakan argumen CLI --add-dir <path>
Selama sesi: gunakan perintah /add-dir
Konfigurasi persisten: tambahkan ke additionalDirectories dalam file pengaturan

File di direktori tambahan mengikuti aturan izin yang sama dengan direktori kerja asli: mereka menjadi dapat dibaca tanpa prompt, dan izin edit file mengikuti mode izin saat ini.

Bagaimana izin berinteraksi dengan sandboxing

Izin dan sandboxing adalah lapisan keamanan pelengkap:

Izin mengontrol alat mana yang dapat digunakan Claude Code dan file atau domain mana yang dapat diaksesnya. Mereka berlaku untuk semua alat (Bash, Read, Edit, WebFetch, MCP, dan lainnya).
Sandboxing menyediakan penegakan tingkat OS yang membatasi akses sistem file dan jaringan alat Bash. Ini hanya berlaku untuk perintah Bash dan proses anak mereka.

Gunakan keduanya untuk pertahanan berlapis:

Aturan deny izin memblokir Claude dari bahkan mencoba mengakses sumber daya terbatas
Pembatasan sandbox mencegah perintah Bash menjangkau sumber daya di luar batas yang ditentukan, bahkan jika injeksi prompt melewati pengambilan keputusan Claude
Pembatasan sistem file di sandbox menggunakan aturan deny Read dan Edit, bukan konfigurasi sandbox terpisah
Pembatasan jaringan menggabungkan aturan izin WebFetch dengan daftar allowedDomains sandbox

Pengaturan terkelola

Untuk organisasi yang memerlukan kontrol terpusat atas konfigurasi Claude Code, administrator dapat menerapkan pengaturan terkelola yang tidak dapat ditimpa oleh pengaturan pengguna atau proyek. Pengaturan kebijakan ini mengikuti format yang sama dengan file pengaturan reguler dan dapat dikirimkan melalui kebijakan MDM/tingkat OS, file pengaturan terkelola, atau pengaturan yang dikelola server. Lihat file pengaturan untuk mekanisme pengiriman dan lokasi file.

Pengaturan khusus terkelola

Beberapa pengaturan hanya efektif dalam pengaturan terkelola:

Pengaturan	Deskripsi
`allowManagedPermissionRulesOnly`	Ketika `true`, mencegah pengaturan pengguna dan proyek dari mendefinisikan aturan izin `allow`, `ask`, atau `deny`. Hanya aturan dalam pengaturan terkelola yang berlaku
`allowManagedHooksOnly`	Ketika `true`, mencegah pemuatan hook pengguna, proyek, dan plugin. Hanya hook terkelola dan hook SDK yang diizinkan
`allowManagedMcpServersOnly`	Ketika `true`, hanya `allowedMcpServers` dari pengaturan terkelola yang dihormati. `deniedMcpServers` masih digabung dari semua sumber. Lihat Konfigurasi MCP terkelola
`blockedMarketplaces`	Daftar blokir sumber marketplace. Sumber yang diblokir diperiksa sebelum mengunduh, jadi mereka tidak pernah menyentuh sistem file. Lihat pembatasan marketplace terkelola
`sandbox.network.allowManagedDomainsOnly`	Ketika `true`, hanya `allowedDomains` dan aturan allow `WebFetch(domain:...)` dari pengaturan terkelola yang dihormati. Domain yang tidak diizinkan diblokir secara otomatis tanpa meminta pengguna. Domain yang ditolak masih digabung dari semua sumber
`sandbox.filesystem.allowManagedReadPathsOnly`	Ketika `true`, hanya jalur `allowRead` dari pengaturan terkelola yang dihormati. Entri `allowRead` dari pengaturan pengguna, proyek, dan lokal diabaikan
`strictKnownMarketplaces`	Mengontrol marketplace plugin mana yang dapat ditambahkan pengguna. Lihat pembatasan marketplace terkelola

Akses ke Remote Control dan sesi web tidak dikendalikan oleh kunci pengaturan terkelola. Pada paket Team dan Enterprise, admin mengaktifkan atau menonaktifkan fitur ini dalam pengaturan admin Claude Code.

Konfigurasi pengklasifikasi mode auto

Mode auto menggunakan model pengklasifikasi untuk memutuskan apakah setiap tindakan aman untuk dijalankan tanpa meminta. Dari kotak itu mempercayai hanya direktori kerja dan, jika ada, remote repositori saat ini. Tindakan seperti mendorong ke org kontrol sumber perusahaan Anda atau menulis ke bucket cloud tim akan diblokir sebagai potensi exfiltration data. Blok pengaturan autoMode memungkinkan Anda memberi tahu pengklasifikasi infrastruktur mana yang dipercaya organisasi Anda. Pengklasifikasi membaca autoMode dari pengaturan pengguna, .claude/settings.local.json, dan pengaturan terkelola. Ini tidak membaca dari pengaturan proyek bersama di .claude/settings.json, karena repositori yang diperiksa masuk dapat sebaliknya menyuntikkan aturan allow-nya sendiri.

Cakupan	File	Gunakan untuk
Satu pengembang	`~/.claude/settings.json`	Infrastruktur terpercaya pribadi
Satu proyek, satu pengembang	`.claude/settings.local.json`	Bucket atau layanan terpercaya per-proyek, gitignored
Seluruh organisasi	Pengaturan terkelola	Infrastruktur terpercaya yang diberlakukan untuk semua pengembang

Entri dari setiap cakupan digabungkan. Pengembang dapat memperluas environment, allow, dan soft_deny dengan entri pribadi tetapi tidak dapat menghapus entri yang disediakan pengaturan terkelola. Karena aturan allow bertindak sebagai pengecualian untuk aturan blokir di dalam pengklasifikasi, entri allow yang ditambahkan pengembang dapat menimpa entri soft_deny organisasi: kombinasinya aditif, bukan batas kebijakan keras. Jika Anda memerlukan aturan yang tidak dapat dilewati pengembang, gunakan permissions.deny dalam pengaturan terkelola sebagai gantinya, yang memblokir tindakan sebelum pengklasifikasi dikonsultasikan.

Tentukan infrastruktur terpercaya

Untuk sebagian besar organisasi, autoMode.environment adalah satu-satunya bidang yang perlu Anda atur. Ini memberi tahu pengklasifikasi repositori, bucket, dan domain mana yang dipercaya, tanpa menyentuh aturan blokir dan allow bawaan. Pengklasifikasi menggunakan environment untuk memutuskan apa arti “eksternal”: tujuan apa pun yang tidak terdaftar adalah target exfiltration potensial.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

Entri adalah prosa, bukan regex atau pola alat. Pengklasifikasi membacanya sebagai aturan bahasa alami. Tulislah cara Anda akan mendeskripsikan infrastruktur Anda kepada insinyur baru. Bagian lingkungan yang menyeluruh mencakup:

Organisasi: nama perusahaan Anda dan apa Claude Code terutama digunakan, seperti pengembangan perangkat lunak, otomasi infrastruktur, atau rekayasa data
Kontrol sumber: setiap GitHub, GitLab, atau org Bitbucket yang didorong pengembang Anda
Penyedia cloud dan bucket terpercaya: nama bucket atau awalan yang Claude harus dapat membaca dan menulis
Domain internal terpercaya: nama host untuk API, dashboard, dan layanan di dalam jaringan Anda, seperti *.internal.example.com
Layanan internal kunci: CI, registri artefak, indeks paket internal, tooling insiden
Konteks tambahan: batasan industri yang diatur, infrastruktur multi-tenant, atau persyaratan kepatuhan yang mempengaruhi apa yang harus diperlakukan pengklasifikasi sebagai berisiko

Template awal yang berguna: isi bidang dalam tanda kurung dan hapus baris apa pun yang tidak berlaku:

{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

Semakin spesifik konteks yang Anda berikan, semakin baik pengklasifikasi dapat membedakan operasi internal rutin dari upaya exfiltration. Anda tidak perlu mengisinya sekaligus. Rollout yang masuk akal: mulai dengan default dan tambahkan org kontrol sumber Anda dan layanan internal kunci, yang menyelesaikan false positive paling umum seperti mendorong ke repositori Anda sendiri. Tambahkan domain terpercaya dan bucket cloud berikutnya. Isi sisanya saat blokir muncul.

Timpa aturan blokir dan allow

Dua bidang tambahan memungkinkan Anda mengganti daftar aturan bawaan pengklasifikasi: autoMode.soft_deny mengontrol apa yang diblokir, dan autoMode.allow mengontrol pengecualian mana yang berlaku. Masing-masing adalah array deskripsi prosa, dibaca sebagai aturan bahasa alami. Di dalam pengklasifikasi, prioritasnya adalah: aturan soft_deny memblokir terlebih dahulu, kemudian aturan allow menimpa sebagai pengecualian, kemudian niat pengguna eksplisit menimpa keduanya. Jika pesan pengguna secara langsung dan spesifik mendeskripsikan tindakan yang tepat Claude akan lakukan, pengklasifikasi mengizinkannya bahkan jika aturan soft_deny cocok. Permintaan umum tidak dihitung: meminta Claude untuk “membersihkan repositori” tidak mengotorisasi force-push, tetapi meminta Claude untuk “force-push cabang ini” melakukannya. Untuk melonggarkan: hapus aturan dari soft_deny ketika default memblokir sesuatu yang sudah dijaga pipeline Anda dengan review PR, CI, atau lingkungan staging, atau tambahkan ke allow ketika pengklasifikasi berulang kali menandai pola rutin yang pengecualian default tidak mencakup. Untuk mengencangkan: tambahkan ke soft_deny untuk risiko spesifik lingkungan Anda yang default lewatkan, atau hapus dari allow untuk menahan pengecualian default ke aturan blokir. Dalam semua kasus, jalankan claude auto-mode defaults untuk mendapatkan daftar default lengkap, kemudian salin dan edit: jangan pernah mulai dari daftar kosong.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}

Mengatur allow atau soft_deny mengganti seluruh daftar default untuk bagian itu. Jika Anda mengatur soft_deny dengan satu entri, setiap aturan blokir bawaan dibuang: force push, exfiltration data, curl | bash, production deploys, dan semua aturan blokir default lainnya menjadi diizinkan. Untuk menyesuaikan dengan aman, jalankan claude auto-mode defaults untuk mencetak aturan bawaan, salin ke file pengaturan Anda, kemudian tinjau setiap aturan terhadap pipeline Anda sendiri dan toleransi risiko. Hanya hapus aturan untuk risiko yang infrastruktur Anda sudah mitigasi.

Tiga bagian dievaluasi secara independen, jadi mengatur environment saja meninggalkan daftar allow dan soft_deny default utuh.

Periksa default dan konfigurasi efektif Anda

Karena mengatur allow atau soft_deny mengganti default, mulai kustomisasi apa pun dengan menyalin daftar default lengkap. Tiga subperintah CLI membantu Anda memeriksa dan memvalidasi:

claude auto-mode defaults  # the built-in environment, allow, and soft_deny rules
claude auto-mode config    # what the classifier actually uses: your settings where set, defaults otherwise
claude auto-mode critique  # get AI feedback on your custom allow and soft_deny rules

Simpan output claude auto-mode defaults ke file, edit daftar untuk mencocokkan kebijakan Anda, dan tempel hasilnya ke file pengaturan Anda. Setelah menyimpan, jalankan claude auto-mode config untuk mengonfirmasi aturan efektif adalah apa yang Anda harapkan. Jika Anda telah menulis aturan kustom, claude auto-mode critique meninjau mereka dan menandai entri yang ambigu, berlebihan, atau mungkin menyebabkan false positive.

Prioritas pengaturan

Aturan izin mengikuti prioritas pengaturan yang sama dengan semua pengaturan Claude Code lainnya:

Pengaturan terkelola: tidak dapat ditimpa oleh tingkat lain apa pun, termasuk argumen baris perintah
Argumen baris perintah: penggantian sesi sementara
Pengaturan proyek lokal (.claude/settings.local.json)
Pengaturan proyek bersama (.claude/settings.json)
Pengaturan pengguna (~/.claude/settings.json)

Jika alat ditolak di tingkat mana pun, tidak ada tingkat lain yang dapat mengizinkannya. Misalnya, deny pengaturan terkelola tidak dapat ditimpa oleh --allowedTools, dan --disallowedTools dapat menambahkan pembatasan di luar apa yang ditentukan pengaturan terkelola. Jika izin diizinkan dalam pengaturan pengguna tetapi ditolak dalam pengaturan proyek, pengaturan proyek memiliki prioritas dan izin diblokir.

Contoh konfigurasi

Repositori ini mencakup konfigurasi pengaturan pemula untuk skenario penerapan umum. Gunakan ini sebagai titik awal dan sesuaikan dengan kebutuhan Anda.

Lihat juga

Pengaturan: referensi konfigurasi lengkap termasuk tabel pengaturan izin
Sandboxing: isolasi sistem file dan jaringan tingkat OS untuk perintah Bash
Autentikasi: atur akses pengguna ke Claude Code
Keamanan: perlindungan keamanan dan praktik terbaik
Hook: otomatisasi alur kerja dan perluas evaluasi izin

Konfigurasi

​Sistem izin

​Kelola izin

​Mode izin

​Sintaks aturan izin

​Cocokkan semua penggunaan alat

​Gunakan specifier untuk kontrol terperinci

​Pola wildcard

​Aturan izin khusus alat

​Bash

​Read dan Edit

​WebFetch

​MCP

​Agent (subagents)

​Perluas izin dengan hook

​Direktori kerja

​Bagaimana izin berinteraksi dengan sandboxing

​Pengaturan terkelola

​Pengaturan khusus terkelola

​Konfigurasi pengklasifikasi mode auto

​Tentukan infrastruktur terpercaya

​Timpa aturan blokir dan allow

​Periksa default dan konfigurasi efektif Anda

​Prioritas pengaturan

​Contoh konfigurasi

​Lihat juga

Sistem izin

Kelola izin

Mode izin

Sintaks aturan izin

Cocokkan semua penggunaan alat

Gunakan specifier untuk kontrol terperinci

Pola wildcard

Aturan izin khusus alat

Bash

Read dan Edit

WebFetch

MCP

Agent (subagents)

Perluas izin dengan hook

Direktori kerja

Bagaimana izin berinteraksi dengan sandboxing

Pengaturan terkelola

Pengaturan khusus terkelola

Konfigurasi pengklasifikasi mode auto

Tentukan infrastruktur terpercaya

Timpa aturan blokir dan allow

Periksa default dan konfigurasi efektif Anda

Prioritas pengaturan

Contoh konfigurasi

Lihat juga