hermes - 💡(How to fix) Fix fix(cli, tui): /sessions unknown command in classic CLI + chmod breaks TUI build on Windows [1 comments, 1 participants]

Summary

Two Windows-specific bugs found after commit 09a491464 which added the /sessions slash command.

Bug 1: /sessions unknown command in classic CLI

Root cause: The /sessions command was registered in the central CommandDef registry (hermes_cli/commands.py:113) so it shows up in /help and autocomplete, but the handler was only implemented in the TUI (ui-tui/src/app/slash/commands/session.ts). The classic CLI's process_command() in cli.py has no elif canonical == "sessions" branch, so typing /sessions in the default REPL mode prints "Unknown command."

Bug 2: hermes --tui build fails on Windows

Root cause: The build script in ui-tui/package.json ends with && chmod +x dist/entry.js. On Windows, chmod is not a valid command, causing npm run build to exit with a non-zero code. The _make_tui_argv() function in hermes_cli/main.py then prints "TUI build failed" and exits — even though all compilation steps (esbuild, tsc, babel) actually succeed.

Fix (PR-ready)

Two small changes:

1. ui-tui/package.json — Remove && chmod +x dist/entry.js from the build script. The execute bit is irrelevant on Windows, and on POSIX the file permission is cosmetic since the TUI launcher always invokes it via node dist/entry.js.

2. cli.py — Add elif canonical == "sessions" to process_command() with a _handle_sessions_command() method that opens SessionDB, calls _session_browse_picker() (reused from hermes_cli.main), and relaunch() to resume the selected session.

How to reproduce

Bug 1:

hermes
> /sessions
Unknown command: /sessions

Bug 2 (Windows):

hermes --tui
TUI build failed.
# ... esbuild succeeds but chmod fails

Environment

• Windows 10
• Hermes after commit 09a491464
• git-bash (MSYS2) shell