Bug OpenClaw 2026.7.1-2: Attachment Base64 Bisa Membuat Gateway OOM

Ada bug OpenClaw yang perlu diperhatikan jika Gateway dipakai sebagai endpoint OpenResponses untuk menerima file atau gambar dalam format base64. Attachment besar yang masih berada di bawah limit konfigurasi dapat menghabiskan heap Node.js, mematikan proses Gateway, memutus request yang sedang berjalan, lalu memicu restart container atau service.

Bug ini dilaporkan pada 18 Agustus 2026 melalui issue resmi #126015 dan diklasifikasikan P1 dengan dampak crash loop. Fix-nya sudah di-merge ke branch main pada 19 Agustus melalui PR #126017. Namun saat audit ini dilakukan, fix tersebut belum tersedia di NPM stable 2026.7.1-2 maupun beta 2026.8.1-beta.2.

Jadi keputusan operasionalnya cukup jelas: operator yang mengaktifkan POST /v1/responses sebaiknya menahan upload base64 besar sampai rilis yang membawa commit perbaikannya tersedia dan lolos smoke test.

Status per 20 Agustus 2026: bug terkonfirmasi pada stable 2026.7.1/2026.7.1-2 dan masih ada pada beta 2026.8.1-beta.2. Fix sudah masuk main, tetapi belum ada release baru yang memuatnya.

Apa yang sebenarnya rusak?

Masalahnya bukan karena model AI gagal membaca file. Gateway jatuh lebih awal, ketika OpenClaw membersihkan dan memvalidasi string base64 sebelum input diteruskan ke provider.

Fungsi canonicalizeBase64() pada versi terdampak membangun string hasil dengan menambahkan karakter satu per satu. Di V8, pola ini membuat banyak node string sementara yang tetap hidup sampai proses penggabungan selesai. Input puluhan juta karakter akhirnya membutuhkan heap yang jauh lebih besar daripada ukuran file aslinya.

Laporan resmi mengukur attachment 15 MiB menghasilkan sekitar 20 juta karakter base64 dan menambah 659 MB heap sementara. Prosesnya juga memakan sekitar 4,3 detik hanya untuk canonicalization. Attachment 20 MiB membuat proses Node.js dengan heap sekitar 560 MB berhenti karena out of memory.

Ini menjelaskan kenapa limit ukuran saja belum cukup. File bisa lolos estimasi ukuran dan masih berada di bawah files.maxBytes, images.maxBytes, atau body limit, tetapi proses normalisasi base64 menghabiskan memori sebelum request selesai diproses.

Dampaknya lebih besar daripada satu request gagal

Kalau request terlalu besar lalu API membalas 413 atau 400, dampaknya terbatas pada request tersebut. Bug ini berbeda karena yang mati adalah proses Gateway.

Pada deployment container dengan batas memori 1 GB, laporan reproduksi menunjukkan attachment sekitar 10 MiB sudah dapat memicu kegagalan. Efek berikutnya bisa berupa:

• koneksi client putus tanpa respons yang rapi;
• turn yang sedang berjalan hilang;
• seluruh sesi pada proses Gateway ikut terinterupsi;
• container atau supervisor me-restart service;
• request yang diulang otomatis dapat menciptakan restart loop.

Issue tersebut menyebut pola ini sebagai self-DoS. Istilah itu masuk akal, tetapi konteks otorisasinya tetap penting. Dokumentasi resmi OpenClaw menegaskan bahwa endpoint HTTP OpenResponses dinonaktifkan secara default dan harus dianggap sebagai akses operator penuh. Endpoint ini seharusnya berada di loopback, tailnet, atau private ingress, bukan dibuka langsung ke internet.

Dengan kata lain, ini bukan alasan untuk mengekspos /v1/responses secara publik. Justru bug ini memperkuat alasan agar permukaan HTTP Gateway tetap sempit dan hanya dapat dipanggil client yang dipercaya.

Siapa yang berisiko terkena?

Risikonya paling relevan pada setup berikut:

1. gateway.http.endpoints.responses.enabled diaktifkan;
2. aplikasi mengirim input_file atau input_image dengan source base64;
3. limit file atau gambar dinaikkan untuk menerima attachment besar;
4. Gateway berjalan di VPS kecil atau container dengan memory cap;
5. client memiliki retry otomatis saat koneksi terputus.

Dokumentasi OpenResponses saat ini menyebut default files.maxBytes sebesar 5 MB, images.maxBytes sebesar 10 MB, dan body request 20 MB. Operator yang tidak mengubah limit tetap perlu waspada pada image base64 besar, terutama jika baseline RAM Gateway sudah tinggi. Setup yang menaikkan limit file atau image mendekati 20 MB punya margin yang lebih sempit.

Workflow chat biasa yang tidak memakai /v1/responses untuk attachment base64 tidak otomatis terkena jalur yang sama. Jangan menyimpulkan semua upload Telegram, WhatsApp, atau Control UI pasti crash. Scope laporan resminya spesifik pada pemrosesan base64 di endpoint tersebut, walaupun helper yang diperbaiki berada di package media-core.

Fix yang sudah masuk ke main

Commit 80dcef5 mengubah cara canonicalizeBase64() bekerja.

Input base64 yang sudah canonical sekarang dikembalikan tanpa membuat salinan baru. Jika input mengandung whitespace, implementasi baru baru mengalokasikan satu buffer ketika whitespace pertama ditemukan. Ukuran buffer dibatasi oleh panjang input, bukan jumlah karakter atau jumlah potongan string.

Menurut evidence pada PR resmi:

• attachment 15 MiB turun dari 659 MB heap sementara menjadi nyaris tanpa tambahan heap untuk input canonical;
• waktu canonicalization turun dari sekitar 4,3 detik menjadi sekitar 0,2 detik;
• payload 20 MiB dapat melewati pengujian heap 560 MB tanpa OOM;
• pengujian diferensial 22.023 input tidak menemukan perubahan hasil validasi;
• test baru mencakup payload besar, base64 dengan whitespace, dan pola adversarial dengan whitespace di antara banyak karakter.

Perbaikannya fokus dan masuk akal. Yang belum boleh dilakukan adalah menganggap commit di main sama dengan paket release. Registry NPM saat audit masih menunjuk latest ke 2026.7.1-2 dan beta ke 2026.8.1-beta.2. Kedua tag itu masih membawa implementasi lama.

Mitigasi sebelum release perbaikan tersedia

Workaround-nya tidak perlu rumit. Untuk sementara, hindari jalur yang sudah terbukti bermasalah.

1. Nonaktifkan endpoint jika tidak dipakai

/v1/responses memang disabled by default. Jika integrasi Anda tidak membutuhkannya, jangan mengaktifkan endpoint hanya untuk berjaga-jaga. Permukaan yang tidak aktif tidak perlu diproteksi dari request attachment.

2. Hentikan sementara base64 attachment besar

Pada versi terdampak, jangan kirim file atau image base64 berukuran besar melalui endpoint ini. Gunakan jalur upload yang sudah diuji, perkecil file sebelum encoding, atau tahan fitur attachment sampai release fix tersedia.

Jangan mengandalkan body limit sebagai satu-satunya perlindungan. Root cause-nya terjadi pada canonicalization input yang sudah lolos pemeriksaan ukuran awal.

3. Audit retry client

Retry tanpa backoff dapat mengubah satu crash menjadi restart loop. Pastikan client tidak langsung mengulang request yang koneksinya putus, terutama untuk payload yang sama. Batasi retry, gunakan exponential backoff, dan hentikan pengulangan setelah error koneksi yang berulang.

4. Pantau restart dan heap

Tambahkan alert untuk restart count, exit karena OOM, serta lonjakan RSS/heap pada proses Gateway. Supervisor membantu service kembali hidup, tetapi restart otomatis bukan fix. Jika payload yang sama dikirim lagi, proses bisa jatuh lagi.

5. Jangan cherry-pick sembarangan ke production

Fix di main sudah di-merge, tetapi branch utama OpenClaw bergerak cepat dan pada saat audit sudah 1.500 lebih commit di depan beta terakhir. Menarik seluruh main ke production demi satu bug dapat membawa banyak perubahan lain dengan blast radius lebih besar.

Kalau organisasi harus melakukan backport sebelum release resmi, perlakukan itu sebagai build internal: pin commit, build artifact terpisah, jalankan test media-core, uji /v1/responses di container dengan memory cap yang sama, lalu simpan rollback. Untuk kebanyakan operator, menunggu release resmi lebih aman.

Checklist setelah versi patched dirilis

Jangan hanya mengecek nomor versi. Pastikan release notes atau source tag benar-benar memuat commit perbaikannya.

1. Cocokkan tag release dengan commit 80dcef5044c75f74e4f59e83e217d79d69391ffe atau perubahan equivalent di packages/media-core/src/base64.ts.
2. Uji file dan image di bawah limit, dekat limit, dan sedikit di atas limit.
3. Pastikan request yang terlalu besar ditolak dengan 4xx, bukan koneksi putus.
4. Jalankan test di memory cap yang sama dengan production.
5. Pantau heap, RSS, restart count, dan durasi request.
6. Uji retry behavior client ketika server sengaja mengembalikan error.
7. Pastikan endpoint tetap berada di private ingress dan auth Gateway berfungsi.

Smoke test ini penting karena bug muncul pada kombinasi ukuran payload, representasi base64, dan batas heap. Test di laptop dengan RAM besar belum tentu merepresentasikan container produksi 1 GB.

Keputusan operasional

Bug ini material untuk operator yang memakai OpenClaw sebagai OpenResponses Gateway dengan attachment base64. Dampaknya bukan sekadar file gagal dibaca, melainkan proses Gateway dapat mati dan mengganggu semua sesi yang berbagi proses tersebut.

Fix sudah tersedia di source main, tetapi belum berada di stable 2026.7.1-2 atau beta 2026.8.1-beta.2 saat audit dilakukan. Sampai ada release yang benar-benar membawa commit tersebut, hindari base64 attachment besar di /v1/responses, audit retry client, dan jangan membuka endpoint operator ini ke internet publik.

Sumber primer:

• Issue OpenClaw #126015: large base64 attachments OOM-crash the Gateway
• PR OpenClaw #126017: fix large base64 attachments on /v1/responses
• Commit perbaikan 80dcef5
• Dokumentasi resmi OpenResponses API
• GitHub Release OpenClaw 2026.8.1-beta.2
• GitHub Release OpenClaw 2026.7.1-2