hermes - 💡(How to fix) Fix [Bug]: Multiple TUI sessions — only first session gets tools; subsequent sessions lose core toolsets (only honcho remains) [1 participants]

Bug Description

When running multiple hermes --tui sessions simultaneously, only the first session gets the full set of tools (terminal, web, file, browser, etc.). Subsequent TUI sessions either get no tools at all (just connect to the LLM as a plain chat) or only have honcho plugin tools (honcho_profile, honcho_search, etc.) while missing all core hermes-cli tools.

Meanwhile, a simultaneously running Weixin (wechat) session via the gateway has all tools working correctly — the issue appears specific to TUI multi-session.

Steps to Reproduce

1. Start the first TUI session: hermes --tui
2. In the first session, verify tools are available (e.g., /tools or ask a question that needs terminal)
3. In another terminal, start a second TUI: hermes --tui
4. In the second session, check available tools — they are missing or reduced to honcho only
5. (Optional) Start a Weixin conversation through the gateway — that session still has full tools

Expected Behavior

All TUI sessions should have identical tool availability, matching the configured toolsets: [hermes-cli] in config.yaml.

Actual Behavior

Only the first TUI session gets the full toolset. Later sessions are degraded.

A concrete example observed in the affected session:

"Current session I only have honcho series tools (and they failed to init), no bash / curl / execute_code, can't call Github API。"

Architecture Context

All TUI sessions run inside a single tui_gateway process (tui_gateway/entry.py). Each TUI window creates a new AIAgent via _make_agent() in tui_gateway/server.py:1735, which calls _load_enabled_toolsets() → _get_platform_tools(cfg, "cli", ...).

The gateway sessions (Weixin, Telegram, etc.) use gateway/platforms/api_server.py:_create_agent() — a different code path that works correctly.

Suspected Root Cause

_load_enabled_toolsets() at tui_gateway/server.py:864 resolves toolsets from HERMES_TUI_TOOLSETS env var or platform_toolsets.cli in config. When hermes-cli (a composite toolset) is not properly resolved in a subsequent call within the same process, only plugin-registered toolsets (like honcho) remain available, while core tools (terminal, web, file, etc.) are stripped.

Possible mechanisms:

• Tool registry state corruption: get_tool_definitions() in model_tools.py:271 has a _tool_defs_cache keyed by (frozenset(enabled_toolsets), registry._generation, cfg_fp). If the second agent build passes different/incomplete enabled_toolsets, a wrong cache entry is created.
• Race condition: _load_cfg() has a global _cfg_cache with _cfg_lock — concurrent agent builds within the same process may race on config reads.
• Composite toolset resolution: _get_platform_tools() at hermes_cli/tools_config.py:771 resolves composite toolsets (like hermes-cli) to individual toolsets. A failure in this resolution path would leave only plugin toolsets, matching the "honcho-only" symptom.

Environment

• Hermes Agent: v0.11.0 (2026.4.23)
• OS: Linux (WSL2)
• Config: toolsets: [hermes-cli] in config.yaml
• Profiles: single profile (default), DeepSeek v4 Pro
• TUI gateway: single process, multiple sessions

Workaround

• Use HERMES_TUI_TOOLSETS=hermes-cli env var to bypass automatic resolution
• Use separate profiles (--profile) for each TUI session
• Use CLI (hermes chat) instead of TUI for parallel sessions