Bug OpenClaw 2026.7.2 Beta 4: Reset Codex Bisa Macet dan Gateway Kehabisan RAM

OpenClaw 2026.7.2-beta.4 membawa masalah yang layak diperlakukan sebagai blocker untuk operator yang memakai Codex session berumur panjang. Laporan GitHub terbaru menunjukkan dua kegagalan yang saling memperparah: sessions.reset dapat memakai ulang session ID yang sudah dipensiunkan, sementara pemindaian catalog dan file session berulang dapat mendorong konsumsi RAM sampai Gateway crash.

Status per 25 Juli 2026: issue #113434 masih terbuka, berlabel P1, impact:session-state, dan impact:crash-loop. Temuan ini berasal dari OpenClaw 2026.7.2-beta.4 di Windows 11 dengan native Codex runtime. Ini belum membuktikan semua instalasi pasti terdampak, tetapi buktinya cukup konkret untuk menahan beta tersebut dari production.

Ringkasan cepat

Ada dua jalur masalah yang perlu dibedakan:

1. Control UI berulang kali memanggil sessions.catalog.list dan sessions.files.list pada penyimpanan Codex yang besar. Pemindaian itu dapat menaikkan CPU dan RAM Gateway sampai seluruh fungsi melambat lalu proses crash.
2. Saat sessions.reset dijalankan, generasi Codex lama dipensiunkan tetapi replacement session masih memakai ID lama. Turn berikutnya ditolak dengan error Codex session generation is no longer current.

Laporan awal mencatat sekitar 890 rollout file, 460 MB data session, dan lebih dari 8.100 event pada transcript terdampak. Angka tersebut adalah kondisi deployment pelapor, bukan ambang resmi OpenClaw.

Apa yang terjadi pada reset session Codex?

Dalam reproduksi yang dilaporkan, session aktif memiliki satu ID. Operator menjalankan RPC reset resmi melalui Gateway. Proses reset memensiunkan generasi Codex tersebut, tetapi entry pengganti mempertahankan ID yang sama.

Hasilnya kontradiktif: durable binding menyatakan ID lama sudah retired, sementara session pengganti tetap menunjuk ID itu. Saat user mengirim pesan berikutnya, runtime menolak turn dengan pesan:

Codex session generation is no longer current: <session-id>

Bukti tambahan di issue menunjukkan reset biasa dapat mereproduksi kondisi ini pada backup sebelum perbaikan lokal. Setelah pelapor memaksa reset membuat UUID baru dan membangun ulang marker SQLite dengan ID baru, verification turn berhasil dan transcript lama tetap utuh.

Itu belum menjadi fix upstream. Namun invariant yang dibutuhkan cukup jelas: jika reset memensiunkan generasi lama, replacement session harus punya identitas baru dan seluruh durable state harus diperbarui secara atomik.

Kenapa pemindaian catalog bisa menjatuhkan seluruh Gateway?

Masalah kedua bukan sekadar halaman Control UI yang lambat. Pada session store besar, permintaan catalog dan daftar file yang berulang memicu pekerjaan scan yang mahal. Karena pekerjaan tersebut terjadi di Gateway, tekanan resource ikut memengaruhi chat, session lain, dan channel yang tidak sedang membuka catalog.

Pelapor mencatat durasi beberapa request antara sekitar 3,5 sampai 13 detik. Saat request terus berulang, penggunaan RAM naik sampai available memory habis dan Gateway crash.

Dua pull request terkait masih terbuka saat artikel ini ditulis:

• #113171 membatasi dan menggabungkan tekanan refresh sessions.catalog.list;
• #110796 membuat pembacaan transcript untuk sessions.files.list lebih bertahap.

Karena keduanya belum merged, operator tidak boleh menganggap masalah scan sudah beres di release resmi.

Siapa yang paling berisiko?

Risiko tertinggi ada pada instalasi yang memenuhi beberapa kondisi berikut:

• memakai OpenClaw 2026.7.2-beta.4;
• menjalankan native Codex session dalam waktu lama;
• menyimpan ratusan rollout file atau transcript besar;
• sering membuka Control UI pada halaman yang meminta catalog dan file session;
• mengandalkan sessions.reset untuk memulihkan session Codex yang gagal;
• memiliki RAM terbatas tanpa monitoring dan restart guard yang sehat.

Laporan berasal dari Windows 11. Belum ada bukti primer yang cukup untuk menyatakan perilaku identik terjadi di Linux atau macOS. Namun bug lifecycle reset berada di jalur aplikasi, jadi operator lintas platform tetap perlu menguji sebelum rollout.

Mitigasi aman sementara

1. Jangan pasang beta 4 di production

Jika production masih memakai stable 2026.7.1 atau versi yang sudah diuji, jangan naik ke 2026.7.2-beta.4 hanya untuk mengejar fitur baru. Beta memang tempat menemukan regression seperti ini.

2. Pantau RAM Gateway, bukan hanya browser

Kalau Control UI terasa berat, cek proses Gateway. Chrome dapat memicu request berulang, tetapi laporan ini menunjukkan beban utamanya berada pada proses Gateway.

Pantau setidaknya:

• resident memory proses Gateway;
• available RAM host;
• frekuensi dan durasi sessions.catalog.list;
• frekuensi dan durasi sessions.files.list;
• restart atau crash pada periode yang sama.

3. Jangan menghapus transcript sebagai respons pertama

Pelapor berhasil memulihkan session tanpa menghapus transcript lama. Sebelum melakukan repair, backup database SQLite dan state Codex. Menghapus thread hanya akan menghilangkan evidence dan belum tentu memperbaiki binding yang sudah tidak konsisten.

4. Hindari patch bundle manual di production

Issue menyebut perbaikan lokal pada JavaScript terpasang dan marker SQLite. Itu berguna sebagai bukti diagnosis, bukan SOP umum. Nama bundle dapat berbeda, update dapat menimpa patch, dan perubahan state separuh jalan bisa memperburuk session.

5. Uji reset secara end-to-end

Di staging, ambil satu Codex session yang memang boleh diuji. Catat ID sebelum reset, jalankan reset resmi, lalu pastikan:

• ID replacement berbeda dari ID yang dipensiunkan;
• durable marker menunjuk ID baru;
• turn baru selesai normal;
• transcript lama tetap tersedia;
• RAM tidak terus naik saat catalog atau file list dibuka.

Apakah perlu downgrade?

Jika beta 4 sudah dipakai dan gejalanya muncul, jangan downgrade paket secara buta. Issue memperingatkan bahwa migrasi database dapat membuat downgrade tanpa backup versi kompatibel menjadi berisiko.

Urutan yang lebih aman:

1. hentikan traffic yang memicu scan berulang;
2. backup database SQLite, state Codex, dan konfigurasi;
3. simpan log serta ukuran session store;
4. restart Gateway secara terkontrol bila resource sudah kritis;
5. uji recovery pada salinan state;
6. rollback hanya dengan backup yang kompatibel dan acceptance test yang jelas.

Keputusan operasional

OpenClaw 2026.7.2-beta.4 belum layak dijadikan target production untuk deployment yang bergantung pada Codex session. Risiko utamanya bukan fitur kecil yang rusak. Session bisa terkunci setelah reset, lalu aktivitas Control UI pada store besar dapat menekan seluruh Gateway sampai crash.

Untuk operator production, pilihannya sederhana: tahan beta 4, batasi eksperimen ke staging, monitor RAM Gateway, dan tunggu fix reset lifecycle serta pembatasan scan benar-benar merged dan masuk release berikutnya. Setelah patch tersedia, tetap lakukan smoke test pada salinan session store yang ukurannya mendekati production.

Sumber primer

• Issue #113434: Codex sessions.reset reuses retired session ID; catalog/file scans can exhaust Gateway RAM
• Pull request #113171: pembatasan tekanan sessions.catalog.list
• Pull request #110796: pembacaan bertahap sessions.files.list
• GitHub Releases OpenClaw