Windows Desktop: managed agents' first terminal command hangs for the full tool timeout (420s) in the buzz-acp context

[Corvux360]

Summary

On Windows, a Desktop-managed agent (buzz-acp → Hermes Agent ACP harness) hangs on its first terminal tool invocation for up to the full tool timeout (420 s), capturing only ~55 chars of output, then the tool times out. The exact same harness + config executed from a normal console completes the same terminal task in ~25 s. Turns end up taking 15-25 minutes because the model keeps retrying terminal commands.

Environment

• Buzz Desktop v0.5.20 (Windows, Tauri), hosted relay (buzz.xyz communities, relay 0.2.1)
• Agent harness: Hermes Agent v0.20.6 spawned by buzz-acp.exe (agent pool), Windows 11 10.0.22631
• Model: zai/glm-5.3-flash

Reproduction / observations

1. Start a managed agent from Desktop → Agents → Start.
2. DM the agent with an @mention. The turn dispatches fine (ACP prompt arrives, model responds).
3. As soon as the agent uses the terminal tool, the agent log shows:

   API call #1 ... out=222
   tools.terminal_tool: Creating new local environment for task session:...
   ... 420 seconds later ...
   agent.tool_executor: sequential tool terminal timed out after 420.0s
   agent.tool_executor: tool terminal completed (420.01s, 55 chars)
   

   The deterministic "55 chars" partial output repeats across attempts, suggesting the spawned local shell never produces its ready/handshake output in this detached (no console, stdio wired to ACP pipes) context.
4. Control test on the same machine, same config, Hermes one-shot CLI (hermes chat -q "run: echo ...") from a normal console: terminal tool completes, whole turn ~25 s.

Impact

First turns of Desktop-managed agents on Windows take 15-25 minutes when any tool uses the terminal; the model often retries the terminal several times, multiplying the 420 s timeouts.

Additional note

Agents also try to use the buzz CLI from the terminal to reply, but BUZZ_PRIVATE_KEY / BUZZ_RELAY_URL are not present in the terminal subprocess environment (fast auth failure instead of the hang). Passing those through the harness's terminal env would let CLI-based flows work; replying via plain assistant text already works and is preferable.

Question

Is the buzz-acp agent spawn on Windows expected to give child tools a console/DETACHED_PROCESS environment that local-shell tools can use? If there is a recommended env/flag for the harness (e.g. console allocation, persistent-shell off), we'd love to configure it.

Happy to provide full agent logs if useful.