hermes - 💡(How to fix) Fix [Bug]: tui_gateway subprocess boundary prevents CLI-configured state from reaching AIAgent — /browser connect unusable in TUI mode

Bug Description

When Hermes runs in TUI mode (hermes --tui), the tui_gateway spawns HermesCLI (slash command handler) and AIAgent (tool executor) as sibling subprocesses. Any process-level state set by a slash command — environment variables, working directory changes, provider config — is stored only in the HermesCLI subprocess and never propagates to the AIAgent subprocess where browser tools and other runtime-dependent operations actually execute.

This makes /browser connect (and potentially other state-setting commands) non-functional in TUI mode, while working correctly in hermes chat mode where CLI and agent share the same process.

Steps to Reproduce

1. Start Hermes in TUI mode: hermes --tui
2. Type /browser connect — Hermes launches a Chromium instance with --remote-debugging-port=9222
3. The TUI reports success and displays the connected CDP endpoint
4. Send a prompt asking the agent to browse a site (e.g., "open google.com")
5. The agent either:
   • Falls back to headless mode ignoring the connected browser, or
   • Errors with "no CDP endpoint configured"

Expected Behavior

After /browser connect, all browser tool calls should route through the connected Chromium instance — matching the behavior in hermes chat mode.

Actual Behavior

The CDP URL is set only in the HermesCLI subprocess. The AIAgent subprocess never sees it because os.environ is process-local and doesn't cross subprocess boundaries.

Affected Component

Other

Messaging Platform (if gateway-related)

No response

Debug Report

Affected Commands At minimum, /browser connect is affected because it relies on BROWSER_CDP_URL being set. Other slash commands that modify process-level state may be impacted:

• Any command that sets environment variables consumed by agent tools
• Commands that change working directory
• Provider/model configuration changes that rely on process state

External Reports This bug was originally reported against the herm TUI:

• liftaris/herm#82 (https://github.com/liftaris/herm/issues/82) — "Prompts after /browser connect fail to route to connected browser"

The herm issue correctly identified that the same operation works in vanilla hermes chat but fails in any TUI mode, pointing to tui_gateway as the boundary where state is lost.

Related Issues (same class)

• #28753 (https://github.com/NousResearch/hermes-agent/issues/28753) — TUI sessions do not propagate fallback_model/fallback_providers to AIAgent (same subprocess boundary, different config)

Environment

• Hermes Agent: v0.13.0+
• Affected: hermes --tui and any TUI client using tui_gateway (including herm)
• Not affected: hermes chat (in-process mode)

Operating System

Windows 11

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

In tui_gateway/server.py, slash commands are handled by HermesCLI and agent turns are dispatched to AIAgent. When /browser connect runs, it sets the CDP URL via an environment variable or similar process-level state in the HermesCLI subprocess. When the agent executes browser tools, it reads from its own subprocess's environment, which doesn't contain this state.

This is an architectural difference between two Hermes modes:

• hermes chat: HermesCLI and AIAgent run in the same process — environment changes are immediately visible to both.
• hermes --tui (and any external TUI client like herm (https://github.com/liftaris/herm)): tui_gateway spawns HermesCLI and AIAgent as siblings — environment changes are invisible across the subprocess boundary.

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR