hermes - 💡(How to fix) Fix libopentui.so file handle leak fills /tmp with thousands of identical .so copies, exhausting root disk

Bug Report: libopentui.so tmp file leak

Summary

The Hermes TUI Node.js process re-extracts libopentui.so to /tmp on every render cycle instead of reusing a single copy. Over time, this fills the root disk with thousands of identical 4.5MB shared objects.

Environment

• Hermes Agent: v0.14.0 (2026.5.16)
• OS: Ubuntu (Linux 6.17.0-29-generic, x86_64)
• Node.js: Hermes-bundled at ~/.hermes/node/bin/node (v22.x)
• TUI entry: ui-tui/dist/entry.js
• /tmp: On root partition (NOT tmpfs)

Observed Behavior

• Hidden dot-prefixed files appear in /tmp: /tmp/.<hex>-<8-digit>.so
• All files are byte-identical copies of libopentui.so (same md5)
• Each file is ~4.5MB
• New file created every ~6-10 seconds while TUI is active
• Accumulation rate: ~360-600 files/hour (~1.6-2.7 GB/hr, ~38 GB/day)
• Over 2,900 copies found after ~5 hours of TUI uptime (10.8+ GB consumed)
• systemd-tmpfiles default 30-day cleanup is irrelevant — disk fills in ~3 days

File Analysis

$ file /tmp/.f9f3dfe75bcf4fff-00000000.so
ELF 64-bit LSB shared object, x86-64, static-pie linked, interpreter "/lib64/ld-linux-x86-64.so.2"
SONAME: libopentui.so, not stripped

$ readelf -d /tmp/.f9f3dfe75bcf4fff-00000000.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libopentui.so]

$ md5sum /tmp/.*.so | cut -d' ' -f1 | sort -u
(single hash — all copies identical)

The .so is Zig-compiled (no BuildID, static-PIE), SONAME libopentui.so.

Root Cause

The bundled entry.js imports tmpdir from node:os and uses it to extract the native libopentui.so on each TUI render cycle. Node.js os.tmpdir() returns /tmp by default (or $TMPDIR if set). Instead of extracting once and caching at a fixed path (e.g., ~/.hermes/node/lib/libopentui.so), the TUI re-extracts a fresh copy with a randomized filename on every cycle.

Since /tmp is on the root partition (not tmpfs) on this system, these files consume real disk space. The files are never cleaned up by the process.

Workaround (User-Deployed)

1. Cron-based cleanup every 30 min: find /tmp -maxdepth 1 -type f -name '.*.so' -mmin +5 -delete
2. TMPDIR redirect to a larger mount point: export TMPDIR=/mnt/markdown_share/tmp/hermes-tmp
3. These are band-aids — the leak still occurs, just in a less critical location

Suggested Fix

Extract libopentui.so once at install time or first run to a deterministic path under ~/.hermes/, then dlopen it from that fixed location on subsequent runs. Do not re-extract to /tmp on every render cycle.

Alternatively, if the extraction is intentional (e.g., for atomic updates), clean up previous copies after successful extraction instead of leaving them orphaned.

Impact

• Critical for systems where /tmp is on the root partition (most Linux installs)
• Low for systems using tmpfs for /tmp (files lost on reboot, but can still exhaust RAM-based tmpfs)
• Agent becomes unusable when root disk fills — "no disk space" errors on all operations

Reproduction

1. Install Hermes Agent v0.14.0
2. Start the TUI (hermes CLI in interactive mode)
3. Let it run for several hours
4. Observe: find /tmp -maxdepth 1 -name '.*.so' | wc -l grows continuously
5. Observe: du -sh /tmp/.*.so grows at ~1.6-2.7 GB/hr