Hermes TUI: plugin-registered slash commands run in slash-worker split-brain

Summary

In the new hermes --tui, plugin-registered slash commands can execute in a separate tui_gateway.slash_worker subprocess instead of the live TUI gateway/agent process. This can give stale, unbound, or otherwise incorrect results for plugin commands that depend on live process/session/agent state.

/lcm is a concrete example, but the issue is not LCM-specific. It applies to slash commands registered by plugins through PluginContext.register_command() when they are not implemented as native TUI commands.

Reproduction

1. Install or enable a plugin that registers an in-session slash command via register_command(). Example: enable the hermes-lcm plugin with /lcm registration.
2. Start hermes --tui.
3. Use the session normally so the live TUI agent has plugin/runtime state.
4. Run the plugin slash command in the TUI, e.g. /lcm or /lcm doctor.

Expected

Plugin-registered slash commands should execute against the live TUI session context, or should receive explicit live session/agent/plugin state equivalent to the active TUI agent.

For the LCM example, /lcm should report diagnostics for the active TUI agent’s live LCM engine/session.

Actual

Unknown TUI slash commands are first sent to slash.exec in ui-tui/src/app/createSlashHandler.ts. slash.exec runs them through a persistent tui_gateway.slash_worker subprocess:

python -m tui_gateway.slash_worker --session-key <session>

That worker constructs its own HermesCLI instance and processes the command there. Because plugin commands are registered into each process’s plugin manager, a plugin slash command may execute against the worker’s plugin/runtime objects rather than the live TUI gateway/agent objects.

For /lcm, this can show stale or unbound diagnostics such as “no active Hermes session initialized LCM in this process,” even though the live TUI agent’s LCM tools and context handling are working.

Root cause

The TUI has three relevant paths:

• Native TUI commands are found by findSlashCommand() and handled in the TypeScript TUI layer.
• Skill commands and pending-input commands are explicitly prevented from going through the slash worker.
• Generic plugin-registered slash commands are not excluded from slash.exec, so they run in the slash-worker subprocess if HermesCLI.process_command() succeeds there.

command.dispatch does have a plugin-command path using get_plugin_command_handler(), but the frontend only falls back to command.dispatch when slash.exec fails. For a valid plugin command, slash.exec usually succeeds, so the server-process dispatch path is never reached.

Suggested fix

Treat plugin-registered slash commands as first-class TUI/gateway commands instead of generic slash-worker commands. Possible approaches:

• Detect plugin-registered commands before slash.exec and dispatch them through the TUI gateway/server process.
• Extend slash.exec to reject plugin commands the same way it rejects skill/pending-input commands, forcing command.dispatch or a dedicated plugin-command RPC path.
• Pass explicit live session/agent/plugin context into plugin command handlers, and document which plugin command APIs are safe to run out-of-process.

Stateless plugin commands may appear to work today, but plugins that depend on process-local or live session state can return misleading results under the current split-brain path.