
Bug OpenClaw WhatsApp: sendReadReceipts: false Bisa Memutus Pesan Grup Masuk
Satu opsi privasi yang terlihat sederhana di channel WhatsApp OpenClaw ternyata punya risiko operasional yang jauh lebih besar daripada sekadar menyembunyikan centang biru. Issue #124132 melaporkan bahwa channels.whatsapp.sendReadReceipts: false dapat membuat pesan grup berhenti masuk ke linked device, sementara DM tetap berjalan dan status channel masih terlihat sehat.
Bug ini diberi label P1 dan impact:message-loss oleh proyek OpenClaw. Namun statusnya perlu dibaca dengan hati-hati: laporan lapangan menunjukkan hubungan yang kuat, source code mengonfirmasi bahwa nilai false memang menghentikan semua pemanggilan read receipt, tetapi efek server-side pada distribusi pesan grup belum berhasil direproduksi oleh maintainer di setup nyata. Candidate fix melalui PR #124458 juga masih terbuka dan belum masuk release.
Gejalanya mudah disalahdiagnosis
Kasus yang dilaporkan berjalan sekitar dua hari dengan pola berikut:
- pesan personal dan self-chat tetap masuk;
- pesan dari grup tidak mencapai gateway;
- mention di grup terlihat seperti diabaikan;
openclaw channels statustetap melaporkan channel linked, connected, dan healthy;- log gateway tidak menunjukkan error khusus, hanya tidak ada group inbound;
- restart dengan konfigurasi yang sama tidak memulihkan aliran pesan.
Kombinasi ini berbahaya untuk operasi. Operator cenderung menyalahkan mention gating, allowlist, routing agent, atau logic balasan. Padahal message belum pernah masuk ke OpenClaw. Agent tidak punya kesempatan untuk memproses atau menolaknya.
Pelapor memulihkan group inbound dengan mengubah sendReadReceipts menjadi true, lalu merestart gateway. Menurut laporan tersebut, pesan grup kembali masuk segera setelah perubahan itu.
Apa yang sudah terbukti dari source OpenClaw?
Pada source main yang ditinjau 22 Agustus 2026, jalur inbound WhatsApp melakukan early return ketika sendReadReceipts === false. Artinya, OpenClaw tidak memanggil markRead untuk pesan yang diterima pada koneksi tersebut.
Source juga menunjukkan bahwa markRead diteruskan ke operasi readMessages milik Baileys. Untuk grup, target receipt mempertahankan metadata participant. Jadi bagian lokalnya jelas: opsi ini bukan hanya mengubah tampilan centang biru untuk satu chat, tetapi menonaktifkan seluruh pengiriman read receipt dari account terkait.
Yang belum terbukti secara independen adalah klaim bahwa server WhatsApp selalu mensyaratkan receipt tersebut agar terus mengirim pesan grup. Maintainer menyatakan mocked test hanya dapat membuktikan receipt tidak dikirim. Membuktikan throttling atau penghentian delivery membutuhkan linked device dan pengujian live sebelum-sesudah.
Kesimpulan yang aman: ada laporan P1 dengan reproduksi lapangan yang spesifik, ada mekanisme lokal yang konsisten dengan laporan, tetapi causal mechanism di server WhatsApp masih dianggap belum final oleh maintainer.
Dokumentasi resminya masih terlalu sempit
Dokumentasi konfigurasi OpenClaw saat ini menjelaskan opsi tersebut sebagai:
sendReadReceipts: true // blue ticks (false in self-chat mode)
Halaman channel WhatsApp juga menjelaskan bahwa read receipt aktif secara default dan dapat dinonaktifkan secara global atau per account. Belum ada warning pada dokumentasi live bahwa nilai false dilaporkan dapat mengganggu group inbound.
Ini membuat operator mudah mengambil keputusan yang keliru. Mereka mungkin menonaktifkan receipt supaya bot tidak menandai pesan sebagai sudah dibaca, tanpa sadar bahwa dampaknya diduga berlaku pada koneksi WhatsApp secara keseluruhan.
Ada detail penting untuk self-chat: dokumentasi resmi menyebut turn self-chat memang melewati read receipt meski setting global tetap aktif. Jadi tidak perlu mematikan sendReadReceipts untuk seluruh account hanya demi menjaga perilaku self-chat.
Candidate fix belum mengubah runtime
PR #124458 mengusulkan warning saat sendReadReceipts: false dipakai bersama group messaging. Warning akan muncul pada validasi konfigurasi dan openclaw doctor, ditambah penjelasan pada dokumentasi WhatsApp.
Patch tersebut sengaja tidak memaksa nilai menjadi true dan tidak menolak konfigurasi lama. Itu pilihan yang masuk akal untuk compatibility, tetapi PR masih diblokir oleh dua hal:
- warning harus menghitung effective config pada setup multi-account, termasuk inheritance dari root dan default account;
- klaim server-side perlu bukti linked-device nyata atau wording yang lebih hati-hati.
Karena PR belum merged, stable 2026.7.1-2 dan beta 2026.8.1-beta.2 belum memiliki warning ini. Registry NPM masih menunjuk kedua versi tersebut sebagai latest dan beta saat audit dilakukan.
Langkah pemulihan yang aman
1. Cek konfigurasi root dan per account
Periksa dua lokasi berikut tanpa menampilkan credential atau isi auth session:
channels.whatsapp.sendReadReceipts
channels.whatsapp.accounts.<id>.sendReadReceipts
Pada instalasi multi-account, jangan hanya membaca nilai root. Account tertentu bisa punya override sendiri atau mewarisi nilai dari konfigurasi parent.
2. Jika account mengikuti grup, gunakan true
Baseline paling aman saat ini:
{
channels: {
whatsapp: {
sendReadReceipts: true
}
}
}
Untuk account yang khusus DM atau self-chat, keputusan privasi bisa dinilai terpisah. Jangan menerapkan false secara global pada account yang dibutuhkan untuk monitoring grup produksi.
3. Restart melalui jalur service yang resmi
Setelah mengubah konfigurasi, restart gateway melalui supervisor yang memang dipakai instalasi tersebut. Jangan langsung menghapus session atau melakukan pairing ulang. Re-pairing menambah risiko operasional dan pada laporan ini bukan langkah yang dibutuhkan untuk recovery.
4. Uji group inbound dari account lain
Status healthy dan DM yang masih masuk bukan bukti channel grup sudah pulih. Kirim message baru dari participant lain ke grup yang diizinkan, lalu verifikasi message benar-benar muncul pada inbound log atau session OpenClaw.
Uji minimal harus mencakup:
- satu DM masuk;
- satu pesan grup tanpa mention;
- satu pesan grup dengan mention jika mention gating aktif;
- satu balasan keluar dari agent bila policy mengizinkan.
5. Tambahkan synthetic check untuk grup penting
Jika WhatsApp dipakai untuk lead, client, atau operasi internal, health check koneksi saja tidak cukup. Tambahkan pengecekan berkala yang membedakan transport connected dari application message activity. Alarm perlu berbunyi bila DM tetap aktif tetapi tidak ada traffic grup melewati window yang wajar.
Apakah perlu menunggu patch?
Tidak untuk mitigasi. Operator dapat menghindari kondisi yang dilaporkan sekarang dengan mempertahankan sendReadReceipts: true pada account yang mengikuti grup.
Tetap jangan menganggap candidate PR sebagai patch resmi. PR #124458 belum merged, belum punya real-device proof yang diminta reviewer, dan warning multi-account-nya masih perlu perbaikan. Release berikutnya juga perlu dicek berdasarkan changelog final, bukan berdasarkan keberadaan PR.
Kesimpulan operasional
sendReadReceipts: false sebaiknya tidak diperlakukan sebagai toggle kosmetik pada deployment WhatsApp yang bergantung pada pesan grup. Ada laporan P1 bahwa opsi ini dapat memutus group inbound tanpa error, sementara DM dan status channel tetap tampak normal.
Sampai OpenClaw merilis warning atau perubahan resmi, pertahankan nilai true untuk account yang mengikuti grup, restart secara terkontrol setelah koreksi, lalu buktikan recovery dengan pesan grup nyata. Untuk monitoring, ukur application-level delivery. Label connected saja tidak cukup.


