Bug OpenClaw 2026.5.28 yang Perlu Dipantau Sebelum Upgrade Production

OpenClaw 2026.5.28 membawa banyak perbaikan bagus, tetapi rilis ini juga punya beberapa bug report yang terlalu dekat dengan area production. Kalau OpenClaw dipakai untuk channel Telegram, cron, provider fallback, custom auth profile, atau automation yang punya side effect, update ini perlu dibaca dengan kepala dingin.

Artikel ini bukan daftar semua issue. Fokusnya hanya bug yang punya dampak operasional nyata.

Referensi utama: release resmi OpenClaw v2026.5.28, package npm OpenClaw 2026.5.28, dan issue upstream GitHub yang relevan.

Ringkasan Cepat

Verdict praktis: hold-upgrade dulu untuk production.

Alasannya:

• Ada regression provider/model fallback yang bisa membuat fallback chain gagal total.
• Ada issue cron yang bisa menggandakan side effect.
• Ada issue secret reference pada generated models.json.
• Ada risiko Telegram delivery replay yang masih perlu dipantau.
• Di host produksi, sinyal lokal seperti timeout Telegram atau event-loop delay sebelumnya perlu dibersihkan sebelum upgrade besar.

Ini bukan berarti 2026.5.28 buruk. Justru banyak hardening-nya bagus. Tapi operator production tidak boleh hanya membaca changelog positif. Issue wave setelah rilis sama pentingnya.

Bug #88560: Provider Fallback Bisa Rusak Karena Double Prefix

Issue #88560 adalah bug paling penting untuk pengguna provider fallback.

Laporan menyebut regression di 2026.5.28, terutama ketika konfigurasi agent memakai key model fully-qualified seperti anthropic/claude-haiku-4-5.

Dalam kondisi tertentu, OpenClaw bisa memperlakukan model id tersebut seolah masih perlu ditambah provider prefix lagi. Hasilnya menjadi anthropic/anthropic/claude-haiku-4-5.

Masalahnya tidak berhenti di satu kandidat. Laporan menyebut state fallback bisa bocor ke kandidat berikutnya. Jadi kandidat lain ikut dicari dengan model id yang salah, misalnya xai/anthropic/claude-haiku-4-5 atau google/anthropic/claude-haiku-4-5.

Dampaknya berat: fallback chain gagal total. Untuk host yang memakai fallback lintas provider, ini bisa membuat heartbeat, cron, atau main session gagal menjawab.

Status issue saat dicek: closed. Tapi karena npm latest masih 2026.5.28, operator tetap perlu hati-hati sampai ada stable release berikutnya yang jelas membawa fix.

Cara Cek Gejala Double Prefix

Cek log Gateway setelah upgrade atau saat agent gagal fallback.

openclaw logs --follow

Cari pola seperti:

Unknown model: anthropic/anthropic/... Unknown model: xai/anthropic/... Unknown model: google/anthropic/... Requested agent harness "codex" does not support openai/anthropic/...

Kalau pola ini muncul, jangan lanjut utak-atik prompt. Masalahnya kemungkinan bukan prompt, tapi routing model/fallback.

Mitigasi paling aman:

• rollback ke versi stabil sebelumnya,
• atau tunggu stable patch,
• atau uji workaround di staging dengan model id unprefixed sesuai provider catalog.

Untuk production, saya lebih memilih rollback atau hold.

Bug #84976: Cron Non-Codex Bisa Dieksekusi Dua Kali

Issue #84976 masih open dan sangat relevan untuk host yang memakai cron.

Ringkasnya: scheduled cron dengan payload model non-Codex bisa berjalan, melakukan side effect, lalu dieksekusi ulang di model primary Codex. Contoh side effect yang berisiko:

• kirim pesan Telegram,
• tulis file,
• update state,
• jalankan workflow yang tidak idempotent.

Ini jenis bug yang dampaknya langsung terlihat di user: pesan bisa terkirim dua kali, file bisa ditulis dua kali, atau job yang seharusnya sekali menjadi ganda.

Untuk host production, cron duplicate bukan bug kecil. Apalagi kalau cron dipakai untuk monitoring, report, reminder, atau workflow yang menyentuh channel external.

Cara Cek Cron Duplicate

Audit cron yang memakai model non-Codex.

openclaw cron list

Lalu cek job yang:

• payload kind-nya agentTurn,
• payload model memakai model non-Codex,
• prompt-nya mengirim pesan atau menulis state.

Setelah upgrade, jalankan satu job test yang aman dan cek apakah output/channel/state hanya muncul sekali.

Mitigasi:

• tahan upgrade,
• buat side effect idempotent,
• hindari model non-Codex untuk cron yang punya side effect sampai issue jelas,
• pakai delivery bawaan cron jika memungkinkan, bukan tool send manual di prompt,
• jangan test di channel production dulu.

Bug #88562: models.json Bisa Menulis apiKey Sebagai String

Issue #88562 menyentuh custom provider dan auth profile.

Masalahnya: derived per-agent models.json bisa menulis field apiKey sebagai string seperti TENSORIX_API_KEY, padahal yang diharapkan adalah structured secret reference.

Dampaknya bisa muncul sebagai warning PLAINTEXT_FOUND di openclaw security audit --deep. Untuk operator yang memakai custom provider, ini perlu dicek karena menyentuh boundary credential.

Jalankan:

openclaw security audit --deep

Kalau ada warning terkait agents/*/agent/models.json, inspect file terkait:

cat ~/.openclaw/agents/main/agent/models.json | jq '.providers'

Yang dicari bukan hanya apakah value tersensor. Yang penting adalah bentuknya: secret reference harus tetap structured, bukan string polos.

Mitigasi:

• jangan publish credential mentah ke config,
• cek generated agent models.json setelah upgrade,
• rollback kalau audit mulai memberi warning credential yang tidak ada di versi sebelumnya,
• tunggu patch kalau setup memakai banyak custom provider.

Bug #51628: Telegram Delivery Queue Bisa Replay Pesan Lama

Issue #51628 bukan issue baru dari 2026.5.28, tetapi masih relevan karena channel delivery tetap jadi area penting di rilis ini.

Masalahnya: setelah sendMessage network failure, outbound recovery bisa replay entry lama dari delivery queue. Efeknya:

• user menerima duplicate reply,
• transcript bisa mendapat duplicate delivery-mirror entry,
• conversation terlihat seperti agent menjawab dua kali.

Untuk host yang memakai Telegram sebagai channel utama, ini perlu dipantau. Apalagi kalau network sedang tidak stabil atau Telegram API sempat timeout.

Cara Cek Telegram Replay

Cek log Gateway:

openclaw logs --follow

Atau inspect delivery queue jika ada gejala duplicate:

find ~/.openclaw -path 'delivery-queue' -type f

Yang dicari:

• pesan yang sama terkirim lagi setelah delay,
• entry delivery-mirror duplicate,
• error sendMessage failed,
• retry yang tidak jelas idempotency-nya.

Mitigasi:

• pantau channel setelah upgrade,
• jangan upgrade saat Telegram API atau network sedang tidak stabil,
• kalau duplicate muncul, simpan log sebelum restart supaya root cause bisa dilacak.

Sinyal Lokal Yang Perlu Diperhatikan

Pada snapshot monitor Rama Digital, host lokal secara umum hidup:

Gateway: reachable Telegram: OK Event loop: OK saat snapshot Security audit: 0 critical

Tapi log sebelumnya masih menunjukkan timeout Telegram dengan indikasi timer delay/event-loop starvation. Ini bukan berarti host rusak, tapi cukup untuk menahan upgrade production.

Untuk runtime agent, timing seperti ini penting. Kalau event loop sempat delay 29-30 detik, efeknya bisa merembet ke channel probe, cron turn, dan delivery retry.

Jadi sebelum upgrade, bersihkan dulu sinyal lokal:

openclaw status --deep --timeout 30000 openclaw channels status --probe --timeout 30000 openclaw security audit --deep openclaw logs --follow

Kalau semua bersih beberapa jam, baru upgrade test lebih masuk akal.

Bugfix Yang Tetap Bernilai Di 2026.5.28

Walaupun verdict production masih hold, 2026.5.28 membawa banyak perbaikan yang layak dicatat:

• session lock lebih aman saat timeout abort,
• Codex app-server/helper failure tidak mudah merusak shared runtime,
• Telegram polling dan WhatsApp profile auth root mendapat perbaikan,
• Teams service URL trust check diperketat,
• cron transient rate limit handling lebih baik,
• browser/tool input validation lebih strict,
• plugin dan Gateway hot path lebih hemat,
• provider/media support bertambah.

Jadi update ini bukan rilis yang perlu diabaikan. Ini rilis yang perlu ditunggu patch stabil berikutnya atau diuji lebih ketat.

Checklist Keputusan Upgrade

Sebelum upgrade production ke 2026.5.28, jawab dulu:

1. Apakah host memakai fallback model lintas provider?
2. Apakah cron mengirim pesan atau menulis file/state?
3. Apakah Telegram adalah channel utama?
4. Apakah ada custom provider dengan auth profile?
5. Apakah ada waktu rollback kalau upgrade gagal?
6. Apakah staging sudah dites?

Kalau jawaban ya ada di poin 1-4 dan staging belum jalan, tahan dulu.

Verdict

OpenClaw 2026.5.28 adalah rilis hardening besar yang menarik. Tapi untuk production, bug yang muncul terlalu dekat dengan area operasional: provider fallback, cron side effect, secret reference, dan Telegram delivery.

Rekomendasi Rama Digital: jangan auto-upgrade production ke 2026.5.28. Pakai staging dulu, tunggu stable patch berikutnya, atau tetap di 2026.5.22 kalau host sedang stabil.

Untuk operator, keputusan terbaik bukan upgrade paling cepat. Keputusan terbaik adalah upgrade saat failure mode sudah jelas dan rollback plan sudah siap.