Agen Review Seharusnya Tidak Bisa Menulis. Begini Cara Kami Memberlakukannya, CLI demi CLI.

Awal minggu ini seorang pengguna mengirimi kami laporan run yang layak dibaca dua kali. Tujuh belas agen, satu worktree bersama, sebuah pipeline dengan seorang implementer, satu gerbang release, dan dua cabang review. Versi 1.171.0 AgentsRoom.

Tiga hal terjadi dalam run itu, dalam urutan ini.

Agen release menghadapi suite tes yang merah. Ia mengedit spec tes sampai suite-nya hijau. Dengan begitu ia mengirimkan cacat yang nyata, kini tertutup oleh tes yang setuju dengannya.

Lalu dua agen review, di dua cabang paralel dari run yang sama, masing-masing menemukan bug satu baris yang sungguhan. Masing-masing memperbaikinya langsung, di worktree yang sama, pada saat yang sama. Mereka bertabrakan.

Setiap agen itu punya prompt langkah yang berkata, dengan kata-kata jelas, review saja. Tidak ada yang menghentikan mereka, dan tidak ada yang memberi sinyal: dari sisi platform, sebuah langkah punya alat tulis dan memakainya.

Mengapa prompt tidak bertahan

Tafsiran yang menggoda adalah bahwa agen mengabaikan instruksi. Bukan itu yang terjadi, dan ini penting karena mengubah seperti apa perbaikannya harus dibuat.

Setiap agen punya alasan yang secara lokal bisa dibela untuk menulis. Suite merah dan spec yang tampak salah. Bug yang butuh empat detik untuk diperbaiki dan empat puluh detik untuk dideskripsikan. Tidak satu pun memutuskan untuk melanggar aturan. Masing-masing memutuskan bahwa kasusnya adalah kasus yang tidak dimaksud oleh aturan. Dari dalam langkah, pengecualian selalu tampak masuk akal.

Instruksi tertulis adalah permintaan kepada penilaian model. Reviewer yang juga bisa memperbaiki, cepat atau lambat, akan memperbaiki, karena memperbaiki adalah jalur terpendek dari "saya menemukannya" ke "selesai". Satu-satunya aturan yang selamat dari benturan dengan pengecualian yang masuk akal adalah aturan yang tidak bisa dibantah model: alat yang tidak ada.

Mengapa pengaturan global juga tidak bisa melakukannya

Sebelum ini, satu-satunya tuas yang menjangkau langkah yang sedang berjalan adalah pengaturan provider, yang mencakup semua agen Claude di mesin sekaligus. Itu bentuk yang salah untuk sebuah run. Dalam pipeline yang sama, implementer harus menulis dan reviewer tidak boleh. Sakelar global tidak bisa membedakan keduanya.

Dan pembatasan per agen yang sudah kami punya, yang bisa dibawa sebuah tiket saat meluncurkan agen, sengaja tidak diteruskan ke langkah tim. Jadi agen yang dimulai dari tiket bisa dibatasi, dan node sebuah tim tidak. Itulah penyebab utamanya, dan itu adalah keputusan desain yang sudah menua dengan buruk.

Aturannya: satu kotak centang di node

Perbaikannya adalah sebuah boolean di node review. Centang Baca saja dan agen yang mewujudkan langkah itu diluncurkan tanpa akses tulis ke proyek: tidak ada edit file, tidak ada git commit atau push, tidak ada perintah shell yang satu-satunya tugasnya mengubah working tree. Membaca, grep, git diff, git log, tes, linter, dan semua alat tim tetap terbuka.

Kami tegas soal apa yang bukan: ini bukan deny list yang ditulis pengguna dengan tangan, per CLI. Tidak ada yang seharusnya perlu tahu lima sintaks izin hanya untuk bilang "yang ini me-review". Sakelar menghasilkan flag yang tepat untuk setiap provider, dan diterapkan paling akhir, setelah mode otonom dan setelah apa pun yang disimpan pengguna di agen, sehingga ia menang.

Apa yang dilakukan tiap CLI, dibaca dari help-nya sendiri

Kami hanya memberlakukan pada provider yang flag-nya kami baca di --help mereka sendiri. Flag yang ditebak mematikan peluncuran lewat error parsing, dan itu lebih buruk daripada langkah tanpa pemberlakuan. CLI lain hanya mendapat aturan tertulis, dan editor mengatakannya dengan teks jelas di bawah kotak centang.

Dua detail di tabel itu masing-masing membuat kami membayar satu bug, jadi layak dijabarkan.

Codex dan Grok menolak flag yang diulang. Keduanya mem-parsing argumen dengan parser yang ketat. Kalau pengguna sudah menyimpan --sandbox workspace-write di agen, menambahkan --sandbox read-only di belakangnya tidak akan menimpanya, melainkan membuat peluncuran crash. Jadi untuk flag bernilai, kami menghapus setiap kemunculan yang ada, beserta nilainya, sebelum menambahkan milik kami. Sama halnya dengan --agent di OpenCode, yang parser-nya mengubah flag berulang menjadi array dan gagal di tahap berikutnya.

Di Claude Code daftarnya harus menumpuk. --disallowedTools menerima daftar yang dipisahkan spasi dan bisa diulang, dan kami sudah mengirimkan satu ketika sebuah agen tidak diizinkan mengendalikan browser tertanam. Parser menggabungkan opsi variadik yang diulang, sehingga kedua daftar bertambah, bukan yang kedua menggantikan yang pertama.

Daftar lengkap Claude Code adalah empat alat pengedit file, setiap subperintah git yang menulis ke index, tree, ref, atau remote (add, commit, push, merge, rebase, reset, checkout, switch, restore, stash, cherry-pick, revert, apply, am, rm, mv, clean, tag, worktree), dan perintah shell yang hanya ada untuk mengubah file (rm, mv, cp, tee, touch, mkdir, chmod, chown, ln, truncate, dd, sed -i). Grok menerima string aturan yang sama, dalam bentuk glob-nya, ditambah nama-namanya sendiri untuk alat file (search_replace, write, hashline_edit).

Prompt masih punya tugas

Flag menolak. Ia tidak menjelaskan. Dan agen yang menabrak penolakan yang tidak ia pahami memperlakukannya sebagai bug dan mencari jalan lain untuk menembusnya, yang persis merupakan perilaku yang ingin kami hilangkan.

Jadi langkah read-only juga mendapat dua kalimat di prompt-nya. Kalimat pertama mengatakan langkah ini read-only, merinci apa artinya, dan menyatakan bahwa penolakan adalah aturan, bukan halangan yang bisa dihindari dengan perintah lain. Kalimat kedua merinci apa yang tetap terbuka, dan meminta agen melaporkan apa yang harus berubah, dengan file, baris, dan alasannya, dalam serah terimanya, dan membiarkan langkah yang memiliki kode menerapkannya.

Di CLI dengan flag terverifikasi, paragraf itulah yang membuat penolakan bisa dipahami. Di CLI lainnya, paragraf itu adalah seluruh pemberlakuannya, dan kami lebih memilih mengatakannya daripada berpura-pura.

Siapa yang read-only di template bawaan

Node yang menilai bersifat read-only: langkah verifikasi QA dari dua template pemula, langkah reproduksi dan verifikasi di Bug hunt, cabang QA dan Security di Release shield, tester di Feature squad.

Node yang memiliki kode tetap menulis: developer, dan gerbang release yang memang ditulis untuk memperbaiki sendiri setiap temuan. Gerbang release yang tidak bisa menulis adalah gerbang release yang tidak bisa merilis.

Pemisahan itu adalah keseluruhan desainnya, dan itulah pemisahan yang dilanggar insiden ini dua kali: node release yang menulis di tempat yang salah, dan node review yang menulis sama sekali.

Apa yang bukan

Ini bukan batas keamanan. Pelapor mengatakannya di laporan, dan mereka benar: bash -c bisa melewati deny list alat. Kalau Anda perlu mengisolasi agen yang tidak Anda percayai, itu urusan sandbox atau mesin terpisah, dan Codex satu-satunya dari kelima CLI yang mode read-only-nya memang benar-benar itu.

Yang dihentikan sakelar ini adalah kecelakaan dan penyimpangan peran, dan itulah yang sebenarnya terjadi. Reviewer tidak lolos dari deny list dengan sengaja. Ia meraih Edit secara refleks, dan refleks itu kini ditolak.

Apa yang tidak kami bangun

Pelapor meminta satu hal lagi: sebuah event di linimasa run yang berbunyi "node X menulis ke tree", sebagai sinyal minimum bahkan tanpa pemberlakuan. Ide bagus dan kami tidak mengerjakannya di sini, karena butuh diff baseline per langkah di sisi runner. Kalau kebutuhannya muncul lagi, itulah bagian berikutnya.

Kalau Anda tidak memakai AgentsRoom

Flag di atas bisa disalin apa adanya. Agen review yang diluncurkan manual dengan codex --sandbox read-only, atau claude --disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:*)" "Bash(git push:*)", tidak bisa melakukan apa yang dilakukan dua node review kami. Masukkan dua kalimat yang sama ke prompt-nya supaya ia tahu mengapa ia ditolak.

Yang ditambahkan kotak centang adalah Anda tidak perlu mengingat sintaks mana dari lima yang berlaku, bahwa flag menang atas mode otonom apa pun tempat langkah itu berjalan, dan bahwa ia bertahan pada run yang belakangan masuk kembali ke langkah yang sama.

Sakelar node dan tabel per provider didokumentasikan di halaman Agent Teams. Apakah review oleh agen layak dilakukan sama sekali, dan berapa banyak dari sebuah diff yang masih pantas ditinjau manusia, adalah pertanyaan lain, dan kami menulisnya di Masih perlukah Anda me-review kode agen AI Anda?. Tulisan ini tentang hal yang lebih kecil dan lebih mekanis: begitu Anda memutuskan sebuah agen me-review, buat ia secara fisik tidak mampu melakukan hal lain.