Hermes Agent 0.20.0 Bisa Macet Saat Update di Windows: Ini Penyebabnya

Pengguna Hermes Agent 0.20.0 di Windows perlu menahan update terburu-buru. Dalam beberapa jam pada 9 Agustus 2026, upstream menggabungkan empat perbaikan yang menyentuh build Desktop, pemeriksaan proses, penghentian backend, dan recovery instalasi.

Masalahnya lebih dalam dari tombol update yang gagal sekali. Ada beberapa failure mode yang saling menumpuk: dependency native tidak terpasang, gateway yang sebenarnya aman dianggap mengunci instalasi, dan child process dapat tertinggal setelah jendela Desktop ditutup. Hasil akhirnya mirip: update berhenti, Desktop tidak bisa dibangun ulang, atau Hermes terus meminta pengguna menutup proses yang kelihatannya sudah tidak ada.

Status per 9 Agustus 2026: release publik terbaru masih Hermes Agent 0.20.0 / v2026.8.3. Fix sudah digabung ke branch main, tetapi belum ada patch release baru. Pengguna release stabil belum otomatis menerima perbaikan ini.

Gejala pertama: Desktop gagal dibangun karena binding Windows hilang

Laporan utama ada di issue #81969. Setelah update, proses build Desktop berhenti dengan error:

get-windows has no win32 prebuilt binding under lib/binding

Error tersebut muncul pada tahap stage-native-deps, bukan saat agent sedang menjalankan model atau tool. Paket [email protected] membutuhkan install script untuk mengunduh native binding Windows. Namun daftar allowScripts di root repository belum mengizinkan script paket itu.

Pada npm yang dipakai Hermes, install script yang tidak masuk allowlist diblokir. Instalasi dependency tetap terlihat berjalan dan warning dapat tenggelam di antara ratusan baris output. Baru saat packaging dimulai, Hermes menyadari binding win32 tidak ada dan build berhenti.

Audit upstream juga menemukan pin Electron yang sudah tidak sinkron. Workspace memakai Electron 40.10.6, sedangkan allowlist masih menunjuk 40.10.2. Ini memperlihatkan akar masalah yang lebih umum: allowlist menggunakan pasangan nama dan versi secara exact. Dependency bump tanpa pembaruan allowlist dapat memblokir postinstall penting tanpa langsung menggagalkan npm install.

PR #82171 memperbaiki tiga hal sekaligus:

• mengizinkan install script [email protected];
• menyelaraskan pin Electron dengan lockfile;
• menambahkan test agar setiap paket yang punya install script wajib memiliki keputusan allowlist yang sesuai dengan versi aktual.

Fix juga menambahkan self-heal. Jika binding get-windows belum ada pada instalasi yang sudah telanjur rusak, tahap packaging mencoba npm rebuild get-windows, lalu memeriksa binding sekali lagi. Ini penting karena npm install biasa tidak selalu mengulang install script paket yang sudah ada di node_modules.

Gejala kedua: updater salah menganggap gateway sebagai blocker

Bug berikutnya ada pada pemeriksaan proses sebelum update. Hermes memang harus menolak perubahan instalasi jika masih ada proses yang benar-benar memakai virtual environment. Guard ini mencegah file diganti ketika interpreter, CLI, atau worker lain masih aktif.

Masalahnya, scanner memotong command line proses menjadi 120 karakter terlalu awal. Pada Windows, path managed runtime dapat sangat panjang. Potongan itu bisa berakhir di tengah path executable, sebelum argumen penting seperti:

-m hermes_cli.main gateway run

hilang dari hasil scan.

Akibatnya, gateway yang seharusnya dikenali sebagai proses yang dapat dihentikan sementara justru diklasifikasikan sebagai blocker asing. Update berhenti dengan pesan bahwa proses Hermes lain masih memakai instalasi, meskipun proses tersebut adalah gateway milik deployment yang sama dan updater sebenarnya punya jalur untuk menanganinya.

PR #82158 memindahkan truncation ke layer tampilan. Matching internal sekarang membaca command line penuh, sedangkan pesan ke pengguna dan JSON scan tetap dipotong setelah redaction agar output tidak terlalu panjang.

Perbedaannya kecil di source, tetapi dampaknya besar. String yang dipakai untuk keputusan lifecycle tidak boleh dipotong untuk alasan presentasi. Data lengkap dipakai untuk klasifikasi; truncation hanya boleh terjadi saat merender output.

Gejala ketiga: jendela sudah tertutup, child process masih memegang instalasi

Ada failure mode lain yang lebih sulit dilihat. Saat update dimulai dari Desktop, Electron menyerahkan proses ke updater lalu menutup backend. Pada Windows, penghentian parent process tidak otomatis menjamin seluruh turunannya selesai.

PR #82179 mendokumentasikan kasus ketika backend python.exe -m hermes_cli.main serve dan managed-runtime child masih hidup setelah jendela Desktop hilang. Updater kemudian memindai virtual environment, menemukan proses tersebut, dan menolak lanjut karena menganggap Desktop masih mengawasinya.

Padahal proses induk Desktop sudah mati. Backend itu sudah orphaned dan tidak akan dihidupkan ulang oleh Electron. Guard yang seharusnya melindungi instalasi berubah menjadi dead end:

1. Desktop menutup jendela dan mencoba menghentikan backend;
2. child process bertahan;
3. updater menemukan holder di virtual environment;
4. updater menolak membunuhnya karena mengira Desktop masih aktif;
5. tidak ada komponen tersisa yang dapat menyelesaikan teardown.

Fix awal menambahkan klasifikasi orphan backend. Hermes memeriksa apakah parent masih hidup dan apakah PID mungkin sudah didaur ulang. Jika backend terbukti orphaned, updater menghentikan seluruh process tree, memindai ulang holder, lalu melanjutkan. Proses non-backend dan kasus yang tidak dapat dibuktikan tetap ditolak. Guard tidak diubah menjadi kill-all.

Follow-up PR #82191 memperbaiki dua detail penting. Pertama, penghentian Desktop sekarang langsung menutup process tree tanpa mengirim pre-signal yang dapat membuat parent keluar lebih dulu. Jika parent sudah hilang sebelum taskkill /T membaca tree, descendant dapat lolos.

Kedua, classifier dibuat tree-aware. Scanner dapat melihat root backend beserta interpreter child yang memakai command serupa. Child tersebut memiliki parent yang masih hidup, tetapi parent-nya justru orphan root yang sedang diproses. Implementasi baru mengelompokkan descendant ke root yang sama, lalu menghentikan tree sekali dari atas.

Maintainer melaporkan pengujian pada Windows 11 dengan root orphan dan tiga descendant. Seluruh tree berhenti, sementara backend dengan Desktop parent yang masih aktif tetap tidak disentuh.

Kenapa satu update bisa memunculkan error yang berbeda

Keempat patch tersebut memperbaiki lapisan yang berbeda dalam satu alur:

1. Dependency install: apakah native binding Windows benar-benar terpasang.
2. Process detection: apakah updater mengenali gateway dan holder lain dengan benar.
3. Desktop teardown: apakah parent dan seluruh child berhenti dalam urutan yang aman.
4. Recovery: apakah instalasi yang sudah telanjur kehilangan binding dapat memperbaiki diri.

Itu sebabnya dua pengguna bisa sama-sama gagal update tetapi melihat pesan yang berbeda. Satu berhenti pada get-windows. Pengguna lain melihat another Hermes process is using this installation. Kasus lain mendapat WinError 5 karena file runtime masih dikunci proses yang tertinggal.

Mencoba satu workaround secara acak belum tentu menyelesaikan semuanya. npm rebuild tidak melepaskan file lock. Menutup jendela tidak menjamin process tree sudah mati. Membunuh semua python.exe juga berisiko menghentikan workload yang tidak terkait.

Keputusan operasional untuk pengguna Windows

Jika Hermes 0.20.0 masih bekerja normal

Tahan update Desktop sampai ada patch release resmi yang memuat rangkaian fix di atas. Jangan mengambil branch main untuk mesin produksi hanya karena commit perbaikannya sudah merge. Branch utama bergerak cepat dan membawa perubahan lain yang belum menjadi release stabil.

Sebelum update berikutnya:

• backup konfigurasi, skill, dan state penting di HERMES_HOME;
• catat tag atau commit yang sedang berjalan;
• siapkan rollback ke instalasi yang masih bisa dibuka;
• hentikan turn, cron, dan worker aktif sebelum update Desktop;
• uji update pada satu mesin Windows lebih dulu sebelum rollout luas.

Jika muncul error get-windows has no win32 prebuilt binding

Jangan menghapus seluruh instalasi atau node_modules secara impulsif. Error ini sudah punya root cause upstream yang jelas: install script native tidak berjalan karena allowlist tidak sinkron.

Self-heal melalui npm rebuild get-windows baru aman diandalkan setelah source yang dipakai sudah memuat perbaikan allowlist. Pada release 0.20.0 lama, menjalankan rebuild tanpa memastikan allowlist dan versi dependency cocok dapat mengulang kegagalan yang sama.

Untuk mesin penting, jalur paling aman adalah mempertahankan backup, menunggu patch release, lalu melakukan update dari keadaan Desktop dan gateway yang benar-benar berhenti.

Jika updater bilang Hermes masih berjalan

Jangan langsung menonaktifkan guard atau memakai kill global. Identifikasi executable, parent PID, dan command line lengkap. Bedakan:

• gateway deployment yang memang boleh dihentikan sementara;
• backend Desktop orphaned;
• CLI atau worker milik sesi lain;
• proses Python yang tidak terkait Hermes.

Jika jendela sudah tertutup tetapi holder masih ada, restart Windows adalah recovery yang lebih aman daripada menghapus file runtime yang masih terkunci. Setelah restart, jangan langsung mengulang in-app update yang sama sebelum ada patch resmi.

Jika update harus dilakukan sekarang

Gunakan mesin staging atau clone environment. Verifikasi minimal:

1. clean install dan update dari 0.20.0;
2. build Desktop menemukan binding get-windows;
3. gateway managed runtime dikenali sebagai pausable, bukan blocker;
4. Desktop teardown tidak meninggalkan serve backend atau descendant;
5. update kedua dari keadaan yang sudah pernah gagal dapat self-heal;
6. config, session, skill, dan state masih terbaca setelah cold start.

Apakah 0.20.0 perlu dihapus?

Tidak ada dasar untuk uninstall massal. Regression ini spesifik pada jalur Windows Desktop, build, dan update lifecycle. Pengguna Linux, macOS, atau instalasi yang tidak membangun Desktop tidak berada pada reproducer utama.

Namun pengguna Windows sebaiknya tidak memperlakukan notifikasi update sebagai aksi satu klik yang bebas risiko. Sampai ada tag baru, posisi yang masuk akal adalah hold pada instalasi yang sehat, backup sebelum mencoba perbaikan, dan jangan menganggap merge ke main sama dengan patch stabil.

Perubahan upstream hari ini cukup meyakinkan bahwa root cause sudah dipahami. Yang belum tersedia adalah release resmi yang merangkum perbaikannya untuk pengguna stable.

Referensi resmi

• Hermes Agent 0.20.0 / v2026.8.3
• Issue #81969: Windows Desktop gagal dibangun setelah update
• PR #82171: sinkronisasi allowScripts dan self-heal get-windows
• PR #82158: command line updater tidak lagi dipotong sebelum matching
• PR #82179: recovery orphaned Desktop backend dan child tree
• PR #82191: tree-aware orphan reap dan teardown tanpa pre-signal
• Issue #82186: in-app update Windows gagal dengan file-lock PermissionError