Bug P0 Hermes Desktop Bisa Menghapus Riwayat Sesi

Hermes Desktop Bisa Menghapus Riwayat Sesi Saat Menekan Enter: Bug P0 Belum Punya Patch Resmi

Menekan Enter untuk mengirim prompt semestinya tidak mengubah riwayat percakapan. Namun pada Hermes Desktop, laporan terbaru menunjukkan submit biasa dapat ikut membawa perintah rewind lama dan memangkas puluhan pesan tanpa konfirmasi yang terlihat.

Kasus ini dicatat sebagai issue #82756, berlabel P0, pada 9 Agustus 2026. Reporter menemukan satu sesi turun dari 364 menjadi 326 pesan, lalu kembali terpangkas dari 328 menjadi 298. Salinan database akhirnya hanya menyisakan sekitar 299 pesan; kira-kira 65 pesan tidak lagi tersedia.

Yang membuat regression ini serius bukan cuma jumlah pesan yang hilang. Pengguna tidak menekan tombol rewind atau edit. Trigger-nya adalah submit dengan Enter biasa, sementara data yang dibuang dihapus dari database dan indeks pencarian tanpa snapshot pemulihan.

Status per 10 Agustus 2026: release publik terbaru masih Hermes Agent 0.20.0 / v2026.8.3. Dua kandidat perbaikan, PR #82811 dan PR #82766, masih open. Belum ada patch resmi atau release stabil yang terverifikasi membawa fix untuk kasus ini.

Apa yang sebenarnya terjadi

Hermes mendukung rewind, edit, regenerate, dan restore dari titik tertentu dalam sesi. Untuk melakukannya, Desktop dapat mengirim parameter truncate_before_user_ordinal. Sederhananya, parameter itu memberi tahu gateway: pertahankan riwayat sebelum giliran pengguna tertentu, lalu buang bagian setelahnya.

Operasi tersebut memang dibutuhkan saat pengguna sengaja kembali ke titik lama. Masalah muncul ketika nilai ordinal dari aksi sebelumnya tetap menempel pada state composer dan ikut terkirim saat submit normal. Helper Desktop juga menambahkan confirm_truncate: true ketika ordinal tersedia.

Dari sisi gateway, request itu tampak sah:

ada target ordinal;
target masih berada dalam rentang riwayat;
ada flag konfirmasi;
gateway menjalankan pemangkasan sebelum memproses prompt baru.

Gateway tidak punya cukup konteks untuk membedakan rewind yang benar-benar diminta pengguna dari nilai lama yang bocor ke submit biasa. Karena ordinal-nya valid, request tidak ditolak sebagai target di luar rentang.

Log yang dilampirkan reporter memperlihatkan target sempat bergerak mundur dari ordinal 110 ke 103 tanpa tindakan rewind atau edit. Itu konsisten dengan target lama atau address space yang bergeser, bukan alur submit normal.

Kenapa pesan yang terpotong sulit dipulihkan

Jalur ini menggunakan replace_messages() untuk menyelaraskan database dengan transcript yang sudah dipangkas. Implementasi saat ini melakukan hard delete terhadap row yang dibuang. Entri terkait di full-text search ikut hilang.

Pada insiden #82756, reporter menyatakan write-ahead log kosong dan tidak ada backup yang dapat dipakai. Jadi ini bukan sekadar daftar pesan yang tidak dirender oleh Desktop. Data yang terpotong benar-benar tidak tersedia dari state database aktif.

Itu perbedaan penting. Bug tampilan biasanya dapat dipulihkan dengan reload, reindex, atau membuka client lain. Hard delete tanpa snapshot membutuhkan backup eksternal; jika backup tidak ada, recovery bisa mustahil.

Ini sudah kejadian ketiga

Issue terbaru menyebut dua insiden sebelumnya dengan pola serupa:

Issue #70516: ordinal stale pada Desktop dilaporkan menghapus 308 pesan.
Issue #80763: submit biasa memangkas sesi dari 296 menjadi 52 pesan; 244 pesan hilang.
Issue #82756: ordinal tetap valid tetapi salah sasaran; sekitar 65 pesan hilang.

Guard pertama di PR #70895 menolak truncation yang mengosongkan seluruh transcript kecuali ada konfirmasi khusus. Guard ini tidak melindungi pemangkasan di tengah sesi karena hasilnya masih berisi pesan.

Guard berikutnya di PR #80802 mewajibkan confirm_truncate untuk pemangkasan non-empty. Perubahan itu benar untuk menolak client yang mengirim ordinal tanpa intent. Namun Desktop dapat otomatis menyertakan flag tersebut ketika ordinal tersisa. Akibatnya, gateway menerima sinyal intent yang secara format valid, meski pengguna hanya menekan Enter.

Dengan kata lain, dua guard sebelumnya memeriksa apakah ada izin untuk memangkas, bukan apakah client dan gateway menunjuk pesan yang sama. Insiden ketiga berada tepat di celah itu.

Kandidat root cause: marker personality ikut dihitung sebagai pesan user

PR #82811 menemukan sumber pergeseran yang lebih spesifik. Hermes menyisipkan marker perubahan personality sebagai pesan role=user agar tetap kompatibel dengan provider yang ketat terhadap posisi system message.

Marker internal seharusnya memiliki display_kind, sehingga tidak ikut dihitung sebagai giliran pengguna nyata. Menurut analisis dan test pada PR tersebut, marker personality belum diberi penanda itu. Gateway dapat menghitung satu slot tambahan yang tidak dilihat client.

Dampaknya sederhana tetapi berbahaya: Desktop meminta rewind ke giliran pengguna ke-N, sementara gateway memetakan N pada ruang indeks yang sudah bergeser. Target tetap valid, tetapi pemotongan mendarat satu giliran terlalu awal.

PR #82811 mengusulkan dua lapis mitigasi:

menandai personality marker sebagai personality_switch agar tidak masuk ordinal pengguna;
mengarsipkan row yang dibuang sebagai inactive, bukan langsung menghapusnya, sehingga salah potong masih punya jalur recovery.

Ini kandidat root cause yang kuat karena disertai failing test pada injection point. Namun statusnya masih proposal code yang belum merge dan belum menjadi release resmi.

Alternatif fix: gunakan message ID, bukan ordinal

PR #82766 mengambil pendekatan lain. Alih-alih hanya mengirim nomor urut, Desktop mengirim truncate_before_message_id dan gateway mencocokkannya dengan ordinal.

Stable identifier lebih tepat untuk operasi destruktif. Nomor urut mudah berubah ketika ada marker internal, compaction, sinkronisasi lintas-client, atau transcript parsial. Message ID semestinya menunjuk satu objek yang sama meskipun posisi relatifnya berubah.

Usulan ini juga menambahkan penolakan ketika ordinal dan message ID tidak cocok, serta membersihkan parameter state setelah submit. Secara desain, itu menutup dua sisi masalah: target lebih stabil dan state lama tidak ikut terbawa ke request berikutnya.

Tetap ada hal yang perlu dituntaskan reviewer, termasuk konsistensi ID antara storage, gateway, dan renderer Desktop. PR #82811 sendiri mencatat bahwa sebagian ID di sisi renderer dapat bersifat ephemeral. Karena itu, belum aman menganggap salah satu PR sudah menjadi fix final sebelum review, merge, test CI, dan release selesai.

Risiko paling tinggi ada pada sesi panjang dan penting

Bug ini relevan terutama untuk pengguna yang menjalankan Hermes Desktop sebagai workspace jangka panjang: riset, coding, operasi bisnis, atau sesi dengan banyak keputusan dan konteks.

Semakin panjang sesi, semakin besar blast radius ketika target rewind bergeser. Satu submit dapat menghapus bukan hanya jawaban model terakhir, tetapi beberapa jam atau hari kerja. Kehilangan itu juga dapat memengaruhi kualitas turn berikutnya karena model menerima transcript yang sudah tidak lengkap.

Remote gateway dan penggunaan beberapa client menambah kompleksitas state, walaupun issue #82756 secara spesifik menunjukkan gateway memiliki history yang fresh dan masalah berada pada target dari front-end. Jadi jangan menyederhanakan kasus ini sebagai masalah koneksi lambat atau database yang belum sinkron.

Mitigasi aman sebelum patch resmi tersedia

1. Backup state sebelum memakai Desktop untuk sesi penting

Cari lokasi HERMES_HOME yang benar pada instalasi Anda, lalu backup state database beserta file pendampingnya saat Hermes sudah berhenti menulis. Menyalin hanya file database saat proses masih aktif dapat menghasilkan backup yang tidak konsisten, terutama jika mode WAL sedang digunakan.

Untuk mesin produksi, gunakan snapshot filesystem atau mekanisme backup yang memahami SQLite. Simpan beberapa versi, bukan satu file yang terus ditimpa.

2. Hindari rewind, edit, regenerate, dan restore pada sesi kritis

Fitur-fitur ini menggunakan jalur truncation yang sedang diperbaiki. Sampai ada release resmi, lebih aman membuat sesi baru untuk cabang eksperimen daripada memundurkan sesi utama yang menyimpan konteks penting.

Ini tidak menjamin submit biasa bebas risiko karena laporan justru terjadi saat Enter normal. Namun menghindari aksi yang mengisi state rewind mengurangi peluang meninggalkan parameter truncation yang kemudian bocor.

3. Jangan lanjut menulis jika jumlah pesan tiba-tiba turun

Jika Desktop mendadak menampilkan history yang lebih pendek, hentikan penggunaan sesi tersebut. Jangan kirim prompt tambahan, compact, atau menjalankan tindakan yang menulis ulang state.

Tutup Hermes secara terkontrol, buat salinan lengkap database beserta -wal dan -shm jika ada, lalu lakukan pemeriksaan pada copy. Menjalankan Hermes terus-menerus dapat mengurangi opsi forensik yang tersisa.

4. Jangan mengedit database produksi secara impulsif

Mengubah flag row, menyalin pesan lintas-sesi, atau menjalankan query recovery tanpa memahami schema dapat memperparah kerusakan. Simpan image asli lebih dulu dan kerjakan hanya pada salinan.

Jika data bisnis atau project bernilai tinggi, recovery sebaiknya ditangani seperti incident database, bukan troubleshooting UI biasa.

5. Pisahkan sesi kerja dan sesi eksperimen

Gunakan sesi pendek untuk menguji personality, edit, regenerate, atau workflow baru. Pertahankan sesi utama sebagai record kerja yang minim operasi rewind. Selain membatasi blast radius, pola ini membuat backup dan verifikasi lebih mudah.

Kapan aman melakukan update

Jangan memakai status PR open sebagai dasar untuk menyatakan masalah selesai. Minimum signal yang layak ditunggu:

issue P0 ditutup dengan fix yang jelas;
PR perbaikan sudah merge;
test gateway dan Desktop lulus di CI;
changelog atau release notes menyebut perbaikan truncation/history loss;
ada tag release baru setelah v2026.8.3;
restore atau recoverability benar-benar diuji, bukan hanya target rewind yang diperbaiki.

Setelah patch tersedia, rollout tetap sebaiknya bertahap. Uji pada salinan profile atau mesin staging dengan skenario submit biasa setelah rewind, perubahan personality, restore checkpoint, sesi panjang, dan reconnect Desktop. Verifikasi jumlah pesan serta database sebelum dan sesudah test.

Kesimpulan operasional

Issue #82756 layak diperlakukan sebagai risiko data, bukan bug kosmetik. Plain-Enter submit dapat terlihat normal di UI tetapi membawa target truncation yang stale atau bergeser. Karena write akhirnya bersifat destruktif, satu salah sasaran dapat menghapus bagian riwayat tanpa jalur undo.

Untuk saat ini, keputusan paling aman adalah backup state, batasi operasi rewind pada sesi penting, hentikan penggunaan jika history menyusut, dan tunggu release resmi yang memuat fix terverifikasi. Dua kandidat patch menunjukkan arah yang masuk akal: perbaiki address space, gunakan identifier stabil, bersihkan state client, dan buat truncation recoverable. Belum satu pun tersedia sebagai patch stabil saat artikel ini ditulis.

Referensi resmi

Tags: #Hermes Agent #Hermes Desktop #P0 bug #session history #data loss #AI agent

Rama Aditya

Founder Rama Digital. Menulis tentang digital marketing, web development, AI, dan sistem operasional untuk bisnis Indonesia.

Tentang Rama Digital