Hindari Prompt Berbahaya di Claude Code: Cegah Push Otomatis dan Tes yang Dilewati

Meminta Claude Code “perbaiki semuanya, langsung push, tes nanti saja” terdengar cepat. Namun pada alat yang bisa mengedit file, menjalankan perintah shell, memakai git, dan membaca dokumentasi, kalimat itu juga bisa menghilangkan kontrol review.

Panduan ini bukan untuk menakut-nakuti. Tujuannya pencegahan. Saya memeriksa dokumentasi resmi Claude Code pada 3 Juni 2026, terutama permission modes, /permissions, settings.json, dan common workflows, lalu mengubah pola berisiko menjadi prompt aman yang bisa dipakai langsung.

flowchart LR
  A["Tulis instruksi"] --> B["Izinkan investigasi"]
  B --> C["Review rencana"]
  C --> D["Edit dengan scope kecil"]
  D --> E["Jalankan tes dan diff"]
  E --> F["Manusia memutuskan push/deploy"]

Apa yang Membuat Prompt Berbahaya

Berbahaya di sini bukan berarti jahat. Maksudnya adalah instruksi dengan scope, wewenang, atau kriteria selesai yang tidak jelas, sementara Claude Code punya akses ke tindakan yang kuat. Untuk pemula, batas izin adalah garis tempat agen harus meminta konfirmasi sebelum mengedit file, menjalankan perintah, atau bekerja di luar proyek.

Claude Code dapat membaca dan mencari file proyek, mengedit kode, menjalankan tes, dan menggunakan git. Dokumentasi resmi menjelaskan bahwa pada sesi lokal, Claude Code dapat bekerja dengan file dan kemampuan terminal yang tersedia bagi pengguna. Karena itu prompt yang baik perlu menulis apa yang boleh dilakukan dan apa yang tidak boleh dilakukan.

Kalimat berisiko	Pengganti yang aman
Perbaiki semuanya	Sebut file target dan pengecualian, lalu minta rencana dulu
Push kalau sudah selesai	Ringkas diff dan hasil tes; saya yang memutuskan push
Lewati tes	Usulkan pemeriksaan paling kecil yang berguna dan jelaskan jika tidak bisa dijalankan
Cek DB produksi	Gunakan dev/staging saja; buat SQL produksi tanpa menjalankannya
Lewati semua persetujuan	Investigasi di Plan mode, lalu lanjut satu langkah dengan persetujuan
Hapus yang lama	Daftar kandidat hapus dulu; hapus hanya setelah disetujui
Update semua ke latest	Pisahkan security fix, minor update, dan major update
Riset lalu implementasikan	Cantumkan sumber resmi dan pisahkan temuan dari usulan perubahan

Batas Izin dari Dokumentasi Saat Ini

Permission mode Claude Code tidak berubah hanya karena Anda menulis “kerjakan dengan aman” di chat. Di CLI, mode diganti dengan Shift+Tab atau --permission-mode; di IDE dan Desktop lewat pemilih mode; default permanen diatur di settings.json.

Per 3 Juni 2026, mode utama adalah: default, yang bertanya sebelum tindakan selain membaca; acceptEdits, yang otomatis menerima edit file dan operasi filesystem umum; plan, cocok untuk membaca, menjelajah, dan membuat rencana sebelum mengedit; auto, research preview dengan pemeriksaan keamanan latar belakang; dontAsk, yang menolak tool yang belum disetujui; dan bypassPermissions, yang sebaiknya hanya dipakai di container atau VM terisolasi.

Perintah /permissions menampilkan aturan Allow, Ask, dan Deny. Deny menang, jadi tim sebaiknya memblokir force push, pembacaan .env, dan perintah deploy produksi, bukan hanya mengandalkan ingatan. Aturan bersama ditaruh di .claude/settings.json; eksperimen pribadi di .claude/settings.local.json.

settings.json Minimal

Gunakan contoh ini sebagai titik awal dan sesuaikan nama command dengan proyek Anda.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

Kuncinya adalah menahan diri. Aturan luas seperti Bash(*) membuat lapisan persetujuan terlalu tipis. Pre-approve check yang berulang seperti npm run test dan git diff membuat sesi tetap cepat tanpa menyembunyikan operasi berisiko.

Use Case 1: Bugfix

Instruksi berisiko adalah: “Perbaiki semua bagian login dan push kalau berhasil”. Scope terlalu luas, dan aksi remote ikut terbawa.

Tujuan: Memperbaiki bug saat sesi langsung kedaluwarsa setelah login.
Scope: Hanya src/auth/**, src/session/**, dan tests/auth/**.
Dilarang: git push, deploy, akses DB produksi, dan membaca .env.
Proses:
1. Baca file relevan dan sebutkan maksimal 3 kemungkinan penyebab.
2. Ajukan rencana perubahan dan tunggu persetujuan saya.
3. Setelah disetujui, lakukan edit terkecil yang berguna.
4. Jalankan npm run test -- auth dan ringkas kegagalan jika ada.
5. Tutup dengan ringkasan git diff dan risiko tersisa.

Dengan format ini, Claude Code bisa meneliti, mengedit, dan memverifikasi tanpa menghilangkan titik review. Perubahan lintas area yang tidak perlu juga lebih mudah dicegah.

Use Case 2: Refactor

Instruksi berisiko adalah: “Rapikan implementasi lama dan hapus yang tidak perlu”. Kata lama, rapi, dan tidak perlu mudah disalahartikan.

Tujuan: Menggabungkan validasi yang duplikat di modul billing.
Perubahan yang boleh: src/billing/validators.ts dan test terkait.
Jangan ubah: migrations/**, prisma/**, public/**, package-lock.json.
Aturan hapus: Hanya daftar kandidat. Jangan hapus tanpa persetujuan.
Verifikasi: Jalankan npm run test -- billing dan npm run lint.
Output: Laporkan alasan, dampak kompatibilitas, dan tes yang perlu ditambah.

Untuk refactor, daftar pengecualian sering lebih penting daripada daftar target. Migration, lockfile, dan file generated mudah terlihat tidak penting padahal dibutuhkan.

Use Case 3: Review Sebelum Deploy

Instruksi berisiko adalah: “CI lambat, lewati saja dan kirim ke produksi”. --no-verify bisa melewati lebih dari lint, termasuk hooks dan secret scanning.

Tujuan: Melakukan release readiness check singkat.
Command yang boleh: git status, git diff, npm run test -- --runInBand, npm run build.
Command yang dilarang: git push, deploy, --no-verify, npm publish.
Aturan keputusan:
- Berhenti jika tes atau build gagal.
- Ringkas hanya 80 baris terakhir dari log error.
- Laporkan status sebagai Siap / Perlu perbaikan / Tahan keputusan.

Deploy menyentuh pelanggan, pembayaran, indeks pencarian, cache, dan support. Biarkan Claude Code menyiapkan bukti; keputusan release terakhir tetap harus eksplisit oleh manusia.

Use Case 4: Riset dan Dokumentasi

Instruksi berisiko adalah: “Cari info terbaru dan update artikel sesukamu”. Fakta eksternal berubah, jadi sumber dan scope edit harus dipisahkan.

Tujuan: Memperbarui teks tentang permission modes Claude Code.
Sumber: Utamakan dokumentasi resmi dan daftar URL di akhir.
Dilarang: Jangan menyatakan fitur yang tidak dikonfirmasi dokumentasi resmi.
Proses:
1. Buat tabel perbandingan teks artikel saat ini dengan dokumentasi resmi.
2. Usulkan perubahan saja; tunggu sebelum mengedit artikel.
3. Setelah edit, cek link usang dan panjang description.

Untuk tugas riset, perlakukan Claude Code sebagai pemeriksa sumber dan pengatur diff terlebih dahulu, baru kemudian sebagai penulis.

Contoh Kegagalan Konkret

Pertama, retry tanpa batas. “Coba lagi sampai berhasil” dapat mengubah outage menjadi biaya tambahan dan tekanan rate limit. Selalu tulis jumlah percobaan maksimum, jeda, dan kondisi berhenti.

Kedua, secret. Jika key asli ditempel di prompt, nilainya dapat tersimpan di riwayat percakapan, log lokal, dan handoff ke subagent. Nilai harus ada di environment variable atau secret manager; prompt hanya menyebut nama variabel.

Ketiga, dependency upgrade. “Update semua package ke latest” bisa membawa major version dengan breaking changes. Gunakan npm outdated, pisahkan security fix dari update biasa, dan review major update secara terpisah.

Keempat, cleanup dan migration. “Rapikan file DB” bisa dipahami sebagai menghapus riwayat migration. Minta daftar dulu, dan berhenti di SQL yang hanya dihasilkan jika menyentuh data produksi.

Checklist Review

Tempelkan ini di akhir prompt berisiko tinggi.

Pemeriksaan keamanan:
[ ] Saya menyebut file target dan file yang dikecualikan
[ ] git push / deploy / publish dilarang atau wajib approval
[ ] DB produksi, API produksi, dan operasi berbiaya diblokir
[ ] Pembacaan .env, private key, dan data pribadi diblokir
[ ] Saya meminta Plan mode atau rencana sebelum edit
[ ] Saya memasukkan minimal satu test, lint, atau build
[ ] Saya meminta Claude berhenti dan meringkas log saat gagal
[ ] Saya meminta diff final, command yang dijalankan, dan risiko tersisa

Jika Anda ingin template yang bisa dipakai ulang tanpa menulis aturan ini setiap kali, halaman produk menyediakan paket prompt dan checklist. Untuk adopsi tim, CLAUDE.md, pengaturan izin, review gate, dan latihan onboarding dapat dirancang dengan repositori nyata melalui training dan konsultasi Claude Code.

Artikel Terkait

• 7 insiden produksi nyata dengan Claude Code dan prosedur pemulihan
• Panduan lengkap praktik keamanan Claude Code
• Panduan lengkap izin Claude Code
• Alur persetujuan dan desain sandbox Claude Code

Link Resmi

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code common workflows

Hasil setelah saya mencoba langsung: Dalam workflow Masa, yang paling membantu adalah memulai dengan Plan mode, membatasi perubahan ke dua sampai lima file, dan menjaga push/deploy sebagai keputusan manusia. Menghindari prompt berbahaya bukan berarti memperlambat Claude Code; itu membuat serah terima cukup presisi sehingga kerja bisa lebih cepat dan review lebih tenang.