Windows managed Hermes ACP runtime hangs while creating the local terminal environment

[Suited78]

On Windows 11, Buzz Desktop's managed BuzzHermes agent can receive a DM and start Hermes ACP successfully, but the turn then hangs when Hermes invokes its terminal tool. The Buzz UI remains on a status similar to:

Ran terminal: buzz messages send --help

The command itself is not the point of failure: running the installed Buzz CLI directly returns immediately. The managed ACP runtime stalls before the terminal command completes, while creating the local terminal environment. In one reproduction, an orphaned bash.exe remained after its parent process exited.

A second related issue occurs when a new message arrives during the stalled turn: Buzz attempts Steer, but Hermes ACP does not advertise steering support. Buzz falls back to cancel+merge, cancelling the Hermes turn and reporting ACP Internal error with no response.

Steps to reproduce

1. Run Buzz Desktop on Windows 11.
2. Use a managed agent configured as BuzzHermes with the Hermes runtime.
3. The managed agent configuration uses buzz-acp and launches Hermes ACP.
4. Send one owner-authored DM mention to the agent.
5. Allow the agent to process a request that invokes the terminal tool (for example, a local buzz ... --help diagnostic).
6. Observe that the run can remain at:

   Creating new local environment for task default...
   

7. If another message is sent while the turn is active, observe the Steer fallback and cancellation behavior.

Expected behavior

• The managed ACP runtime should create the local terminal environment promptly and execute the command.
• Buzz CLI commands should be resolvable in the managed agent environment, or the harness should use the absolute Buzz CLI path.
• When the agent does not advertise ACP steering support, a new event should be queued rather than cancelling the active turn.
• Stopping or cancelling the managed agent should terminate the complete ACP child process tree, including Git Bash/MSYS descendants.
• A completed Hermes response should be published back to the originating Buzz DM.

Actual behavior

• The run can remain stalled for several minutes at local environment creation.
• No Session snapshot created, local environment ready, or tool terminal completed line appears.
• A bash.exe child was observed with zero CPU usage after its parent process exited.
• When a second message triggers Buzz steering, the log reports:

  steer: no active_run_id and agent did not advertise _session/steering
  falling back to cancel+merge
  Cancelled session ...
  Turn ended ... interrupted_by_user ... response_len=0
  agent_returned ... code -32603 ... Internal error
  

• The direct installed CLI is healthy and returns usage immediately:

  C:\Users\clawl\AppData\Local\Buzz\buzz.exe messages send --help
  

Version and platform

• Buzz version: 0.5.20
• OS: Windows 11
• Managed runtime: Hermes ACP
• Hermes ACP version: 0.20.4
• Model/provider: openai-codex:gpt-5.6-luna
• Managed ACP settings observed: agents=10, subscribe=Mentions, dedup=Queue, meh=Steer, respond_to=owner-only

Logs / additional context

Relevant log sequence from the attached harness log:

2026-08-27 15:07:31 [INFO] tools.terminal_tool: Creating new local environment for task default...
2026-08-27T05:08:29.465760Z WARN buzz_acp::acp: steer: no active_run_id and agent did not advertise _session/steering — falling back to cancel+merge
… omitted 14 diff line(s) across 1 additional file(s)/section(s)