[Bug] Hermes ACP initializes but every managed prompt hangs until 60s timeout on Windows

[godhiraj-code]

Describe the bug

A Buzz Desktop managed Hermes ACP agent initializes successfully, but every incoming prompt hangs until buzz-acp reports a 60-second request timeout.

This happens even for a one-word prompt and is not caused by worker execution, Kanban, or a long model response.

Steps to reproduce

1. Run Buzz Desktop 0.5.3 on Windows 10 AMD64.
2. Configure a managed Hermes Agent ACP runtime using Hermes Agent 0.19.1.
3. Configure an explicit model ID: gpt-5.6-sol.
4. Send a simple prompt such as Hi.
5. Wait for the response.

Expected behavior

The agent should return a short response within a few seconds.

Actual behavior

The message is accepted by Buzz, but no assistant response appears. After approximately 60 seconds, Buzz logs:

Request timeout — agent did not respond within 60s

Buzz then requeues the failed batch and respawns the Hermes ACP process.

Evidence

Buzz's harness log shows that:

• ACP initialization succeeds.
• Hermes creates the OpenAI Codex client successfully.
• The configured model is gpt-5.6-sol.
• MCP tools register successfully.
• No model response or tool event appears before the timeout.

Sanitized log excerpts:

buzz-acp: agent initialized
configured_model=gpt-5.6-sol
OpenAI client created provider=openai-codex model=gpt-5.6-sol
MCP: registered 7 tool(s) from 1 server(s)
Request timeout — agent did not respond within 60s

The same minimal prompt succeeds immediately when run directly through Hermes CLI:

MANAGER_OK

This isolates the failure to the Buzz ACP request/response path rather than Hermes, model authentication, or the model endpoint.

The Buzz startup log also reports:

permission_mode=bypassPermissions

Please confirm whether Buzz sends a session/set_config_option permission-mode request to Hermes ACP. If Hermes does not support that configuration vocabulary, the error may be waiting indefinitely instead of being returned as a handled ACP error.

Environment

• Buzz Desktop: 0.5.3
• OS: Windows 10 AMD64
• Hermes Agent: 0.19.1
• ACP model: gpt-5.6-sol
• Harness: managed Hermes Agent ACP
• Direct Hermes CLI: same machine and credentials, succeeds

Related issues

• buzz-acp: OpenCode-backed agents hang/timeout — session/set_config_option sends Claude-only permission mode values OpenCode rejects #3729 — buzz-acp permission-mode values can cause ACP initialization hangs
• Model dropdown stays empty for ACP harnesses that report models via session/new → models.availableModels (e.g. Hermes Agent) #3934 — Hermes model discovery through models.availableModels
• [Bug] Hermes agent does not work out of the box — managed session missing BUZZ_PRIVATE_KEY and BUZZ_RELAY_URL #3768 — Hermes managed-session provisioning

No credentials, private channel IDs, identity IDs, API keys, or Hindsight data are included.

[TheSmokeDev]

Chased this from both sides — Buzz's ACP client and the Hermes ACP server. Short version: the hang is session/new, not session/prompt, and the wait is Hermes-side. Buzz's IO is correct; two smaller Buzz-side issues made it undiagnosable, and one is worth fixing on its own.

Why it looks like the prompt

session/prompt doesn't use send_request — it's bounded by idle/hard deadlines (DEFAULT_IDLE_TIMEOUT_SECS = 900), and a genuinely stuck prompt would hang ~15 minutes and report "Idle timeout". The reported message is "Request timeout — agent did not respond within 60s", and REQUEST_TIMEOUT = 60 is only reachable through send_request. Of its callers, on a first message with Hermes: initialize demonstrably succeeded, authenticate isn't on the path, the goose system-prompt call is name-gated, and session/set_model / session/set_config_option are each wrapped at 5s (the latter also gated on the agent advertising the mode). That leaves session/new, which is the one hot-path call with no outer wrapper.

And because sessions are created lazily inside the prompt task, the operator experiences session creation as "the prompt hung".

One-look confirmation from a log you already have: search the harness log for created session … for channel …. If it's absent, session/new never returned. Wire-level: RUST_LOG with acp::wire=debug shows → {"method":"session/new"} with no matching ← before the 60s mark.

What Hermes is doing during those 60s

HermesACPAgent.new_session calls SessionManager.create_session synchronously from a coroutine, so AIAgent construction — config load, provider resolution, memory-provider init, a SQLite write — runs on the event loop that serves every request. Its stdio reader hands requests to that loop via call_soon_threadsafe, so a blocked loop doesn't error: it accepts requests and never runs them, and no log line flushes. That's why you see initialization succeed and then total silence rather than a stack.

The usual culprit for exceeding 60s is memory-provider init: NousResearch/hermes-agent#58083 is the same signature (Windows, session/new hangs, mcpServers: []), and its reporter A/B'd it to memory_enabled: true + memory.provider: holographic — 120s+ hang vs 4-7s with memory disabled.

Workaround today: set memory_enabled: false (or drop a slow memory provider) in ~/.hermes/config.yaml.

I filed the full analysis upstream as NousResearch/hermes-agent#78205, including why the obvious asyncio.to_thread fix needs a design decision rather than a patch.

The HERMES_ACP_SKIP_CONFIGURED_MCP escape hatch is leaking

crates/buzz-acp/src/config.rs sets that flag citing #3355 — and Hermes only honors it in entry.py. _make_agent then calls a helper that starts MCP discovery rather than joining it, so the work Buzz asked to skip happens anyway, moved into session/new. Fixed in NousResearch/hermes-agent#78204. #4098 is #3355 recurring one protocol step later, which is why the existing mitigation didn't hold.

Two Buzz-side things I found while tracing

Neither causes #4098, both are real:

1. The timeout names no method. AcpError::Timeout carries only a Duration, and send_request doesn't log which method timed out above debug — so a session/new failure surfaces as a prompt timeout and this issue took a two-codebase trace to place. Threading the method name through makes it a one-line diagnosis. Related: session/new gets 60s while the prompt it precedes gets 900s idle / 7200s hard, so an agent that legitimately needs 90s to provision can never succeed on any runtime.

2. On Windows, respawn orphans the child. kill_process_group is #[cfg(not(unix))] → false, so shutdown falls back to child.start_kill(). With an npm .cmd shim, Rust runs the batch file through an intermediate cmd.exe, so that reaps the wrapper and leaves the real process alive. On this issue's timeout→respawn loop, each cycle strands another live agent.

Happy to send PRs for either if useful — say the word and I'll open them separately.