Izin Claude Code: cara aman mengatur settings.json

Anda hanya ingin Claude Code menjalankan tes, tetapi dialog konfirmasi muncul untuk setiap perintah. Di sisi lain, jika seluruh Bash diizinkan, penghapusan file, hard reset, atau push --force juga bisa berjalan tanpa sempat diperiksa.

Pilihannya bukan sekadar mengonfirmasi semuanya atau mengizinkan semuanya. Konfigurasi awal yang aman dapat menjalankan pembacaan dan tes secara otomatis, meminta persetujuan sebelum mengedit atau mengirim perubahan, serta menolak akses ke rahasia dan operasi destruktif. Ketiga lapisan itu ditulis di settings.json.

Inti panduan ini

Urutan evaluasinya adalah deny → ask → allow: tolak lebih dulu, minta persetujuan sesudahnya, lalu izinkan otomatis.
Pembacaan di dalam proyek sudah berjalan tanpa prompt. Taruh hanya tes yang telah diperiksa di allow, pengeditan, akses eksternal, dan push di ask, serta rahasia dan operasi destruktif di deny.
Bash(git *) terlalu luas karena juga mencakup git reset --hard dan git push --force.
Read(.env) saja tidak dapat membatasi semua proses anak. Gunakan sandbox jika Anda memerlukan batas yang lebih kuat.
Setelah menyimpan konfigurasi, periksa /permissions dan /status untuk memastikan aturan aktif dan file asalnya.

Bagian yang dapat didelegasikan dan bagian yang harus diputuskan manusia

Dapat dikerjakan Claude Code	Harus diperiksa manusia	Selalu ditolak
Mencari file, memeriksa diff, menjalankan tes	Mengedit file, membuat commit atau push, memasang dependensi	Membaca rahasia, force push, hard reset, penghapusan massal
`Read`, `Grep`, `git diff`	`Edit`, `git commit`, `npm install`	`.env`, `git push --force`, `git reset --hard`, `rm -rf`

Operasi yang sulit dipulihkan, mengirim data ke luar lingkungan, atau menyentuh kredensial sebaiknya berada di ask atau deny.

settings.json yang aman untuk memulai

Buat .claude/settings.json di root proyek, lalu mulai dengan konfigurasi berikut. Isinya cukup konservatif untuk dijadikan standar tim dan disimpan di Git.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Edit",
      "WebFetch",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(git clean *)",
      "Bash(git restore *)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(**/secrets/**)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(rm -rf *)",
      "Bash(rm *)",
      "PowerShell(Remove-Item *)"
    ]
  }
}

Baseline ini untuk repositori yang scripts package.json-nya sudah diperiksa. Pada repositori asing, kosongkan allow sampai Anda memahami apa yang dijalankan tes. Bash(npm test *) cocok dengan npm test dan bentuk yang memakai argumen.

Lokasi settings.json

Scope	Lokasi	Kegunaan
User	`~/.claude/settings.json`	Preferensi yang berlaku di semua proyek milik Anda
Project	`.claude/settings.json`	Standar tim yang dibagikan melalui Git
Local	`.claude/settings.local.json`	Pengaturan pribadi untuk komputer ini; jangan masukkan ke Git
Managed	Konfigurasi yang didistribusikan administrator	Kebijakan organisasi yang tidak dapat ditimpa pengguna

Urutan prioritasnya adalah Managed, command line, Local, Project, lalu User. Array seperti permissions.allow digabung antar-scope, bukan diganti seluruhnya. Kecocokan deny tetap dievaluasi sebelum ask dan allow. Simpan aturan bersama di Project dan kebijakan wajib di Managed.

Cara membaca aturan allow, ask, dan deny

Aturan	Arti
`Read`	Cocok dengan seluruh pembacaan bawaan; allow global biasanya tidak perlu di dalam proyek
`Bash(npm test)`	Hanya cocok persis dengan `npm test`
`Bash(npm test *)`	Cocok dengan `npm test` dan argumen setelahnya
`Bash(ls*)`	Dapat ikut mencocokkan `lsof`; cakupannya lebih luas daripada kelihatannya
`Read(//Users/me/secrets/**)`	Path absolut dari root sistem file
`Edit(/src/*/.ts)`	Dalam Project, cocok dengan file TypeScript di bawah `src` proyek
`WebFetch(domain:docs.anthropic.com)`	Cocok dengan WebFetch ke domain tersebut

Aturan Bash(git *) mencakup git push origin main, tetapi juga git reset --hard. Izinkan setiap perintah aman secara spesifik, bukan seluruh Git.

Mengapa Read dan Edit saja belum cukup melindungi rahasia

Pola path untuk Read dan Edit mengikuti sintaks gitignore.

Penulisan	Titik acuan	Contoh
`//path`	Root sistem file	`Read(//Users/me/secrets/**)`
`~/path`	Direktori home	`Read(~/.ssh/**)`
`/path`	Lokasi dasar file konfigurasi	Dalam Project: `Edit(/src/**)`
`path` atau `./path`	Direktori kerja saat ini	`Read(.env)`

Satu garis miring di depan bukan path absolut. Read(.env) mencegah alat bawaan Read membuka file tersebut, tetapi bukan pembatas umum untuk setiap perintah Bash atau proses anak. Skrip Node.js, misalnya, masih bisa membuka file secara langsung jika sistem operasi mengizinkannya.

Jika repositori berisi kredensial, gunakan juga sandbox Claude Code dan pembatasan pada level sistem operasi. Aturan izin dan sandbox adalah lapisan yang saling melengkapi.

Tiga kasus penggunaan

Kasus penggunaan 1: mengotomatiskan tes saja untuk proyek pribadi

Input: kode sumber, tes, dan diff Git. Output: usulan perbaikan dan hasil tes. Pemeriksaan manusia: pengeditan, pemasangan dependensi, commit, dan push.

Mulai dengan konfigurasi minimum dan biarkan Edit berada di ask. Jika suatu operasi aman terus berulang dan efeknya sudah dipahami, pindahkan hanya operasi tersebut ke allow. Jangan mengizinkan seluruh Bash hanya untuk menghilangkan satu dialog.

Kasus penggunaan 2: menolak operasi berbahaya untuk seluruh tim

Input: daftar perintah yang dibutuhkan dan tindakan yang dilarang. Output: konfigurasi yang dilacak di Git. Pemeriksaan manusia: penambahan aturan deny dan pengecualian sementara.

Tulis larangan untuk .env, push --force, dan reset --hard pada scope Project. Jika organisasi perlu memastikan aturan itu tidak dapat diubah pengguna, pindahkan kebijakannya ke Managed settings.

Kasus penggunaan 3: menyelidiki repositori produksi tanpa mengubahnya

Input: log insiden dan riwayat Git. Output: dugaan penyebab dan rencana perbaikan. Pemeriksaan manusia: setiap pengeditan, deployment, atau pengiriman data keluar.

Jalankan Claude Code dalam Plan Mode:

claude --permission-mode plan

Jika penyelidikan memerlukan penulisan file, pindah dulu ke branch kerja atau lingkungan terisolasi. Berikan persetujuan hanya setelah batas kerja itu siap.

Empat kegagalan konkret dan perbaikannya

Kesalahan	Penyebab	Perbaikan
Mengizinkan `Bash(git *)`	Pola yang sama mencakup push dan hard reset	Izinkan hanya perintah yang efeknya sudah diperiksa
Menambah `allow: Bash(aws s3 ls)` di bawah `deny: Bash(aws *)`	Deny menang sebelum ask dan allow; pola spesifik bukan pengecualian	Persempit deny atau pisahkan operasi aman ke perintah lain
Menganggap `Read(.env)` sebagai isolasi OS	Proses Node.js atau Python arbitrer tidak sepenuhnya diblokir	Tambahkan `denyRead` atau aturan credentials sandbox
Menghapus allow Local tetapi perintah masih jalan	Array User, Project, dan Local digabung	Periksa sumber di `/permissions` dan scope di `/status`

Pelajari kasus kegagalan keamanan Claude Code untuk pola insiden dan praktik keamanan terbaik untuk pemeriksaan deployment lengkap.

Memilih permission mode

Mode	Cocok untuk	Hal yang perlu diperhatikan
`default`	Pertama kali membuka suatu repositori	Meminta konfirmasi saat diperlukan
`acceptEdits`	Pekerjaan pengembangan dengan scope yang sudah dipahami	Mengizinkan pengeditan dan operasi file umum
`plan`	Investigasi, desain, atau membaca insiden produksi	Tidak mengubah kode sumber
`auto`	Uji coba tugas panjang dengan pemeriksaan keamanan di latar belakang	Fitur ini masih berkembang; cek dokumentasi terbaru
`dontAsk`	Otomasi non-interaktif dengan operasi yang sudah disetujui	Menolak operasi yang belum diizinkan tanpa bertanya
`bypassPermissions`	Container atau VM yang dapat dibuang	Jangan gunakan di komputer kerja atau lingkungan produksi

Jika sandbox.autoAllowBashIfSandboxed: true, perintah Bash yang berjalan di dalam sandbox dapat dijalankan tanpa pertanyaan walaupun ada aturan ask untuk Bash. Aturan deny yang eksplisit tetap berlaku. Pahami interaksi ini sebelum mengandalkan dialog persetujuan.

Pitfall: izin terlalu luas dan hanya mengandalkan hook

Kesalahan yang sering terjadi adalah memasukkan seluruh Bash ke allow, lalu mengandalkan satu hook PreToolUse untuk menolak operasi berbahaya. Ketika hook gagal dimuat, kondisinya tidak lengkap, atau matcher salah, satu-satunya lapisan perlindungan ikut hilang.

Penyebab: izin dasar terlalu luas dan semua perlindungan bergantung pada satu pemeriksaan dinamis.

Perbaikan: tulis deny eksplisit dan allow yang sempit terlebih dahulu. Gunakan hook sebagai lapisan tambahan untuk keputusan dinamis. Aturan deny dan ask tetap lebih kuat walaupun hook mengembalikan allow.

JSON dan JavaScript yang siap disalin

Simpan JSON di awal artikel sebagai .claude/settings.json. Lalu buat scripts/check-claude-permissions.mjs dengan kode berikut. Skrip ini memastikan JSON dapat dibaca dan empat larangan minimum masih ada.

// scripts/check-claude-permissions.mjs
import { readFileSync } from "node:fs";

const path = ".claude/settings.json";
const settings = JSON.parse(readFileSync(path, "utf8"));
const deny = new Set(settings.permissions?.deny ?? []);
const required = [
  "Read(.env)",
  "Edit(.env)",
  "Bash(git push --force *)",
  "Bash(git reset --hard *)",
  "Bash(rm *)",
  "PowerShell(Remove-Item *)",
];

const missing = required.filter((rule) => !deny.has(rule));
if (missing.length > 0) {
  console.error(`Aturan deny yang belum ada: ${missing.join(", ")}`);
  process.exit(1);
}

console.log("Pemeriksaan izin minimum: OK");

Jalankan dari root proyek:

node scripts/check-claude-permissions.mjs

Pemeriksaan ini bukan bukti bahwa repositori sudah aman. Tujuannya adalah mendeteksi lewat CI jika salah satu larangan minimum terhapus tanpa sengaja.

Urutan pemeriksaan saat konfigurasi tidak bekerja

Buka /permissions, lalu periksa aturan efektif dan file sumbernya.
Gunakan /status untuk melihat lapisan konfigurasi yang dimuat.
Periksa perbedaan kecil yang berdampak besar, seperti Bash(ls *) dan Bash(ls*), atau /path dan //path.
Periksa izin otomatis sandbox serta aturan deny atau ask dari scope yang lebih tinggi.
Pindahkan aturan yang harus dibagikan tim ke .claude/settings.json, bukan membiarkannya hanya sebagai opsi CLI sementara.

Ringkasan

Mulailah dengan menempelkan konfigurasi minimum ke .claude/settings.json, lalu gunakan /permissions untuk memastikan asal setiap aturan.

Taruh hanya tes yang telah diperiksa di allow, pengeditan dan operasi eksternal di ask, serta rahasia dan perintah destruktif di deny. Tambahkan izin setelah memahami efek perintah.

Untuk menerapkan kebijakan ini bersama aturan pengembangan lainnya, lihat materi Claude Code yang berisi template dan checklist siap pakai.

Sumber resmi

Hasil pengujian yang dilakukan

Pada 22 Juli 2026, blok JSON dari sepuluh bahasa diuraikan dengan JSON.parse, lalu pemeriksaan Node.js dijalankan di proyek sementara. Dengan enam deny wajib, proses selesai dengan kode 0; tanpa Bash(git reset --hard *), kode 1 dan nama aturan yang hilang ditampilkan.

Pengujian hanya memakai data rekaan: tidak ada kredensial, repositori klien, atau data produksi, sehingga hasil ini bukan rekam jejak dari penerapan di sistem nyata. Tampilan izin juga dapat berbeda menurut sistem operasi dan versi Claude Code; tetap periksa /permissions dan /status di lingkungan Anda sendiri.