[Regression] Buzz Desktop managed agents can't reply again: the ACP gateway attach model drops harness BUZZ_* credentials (re-opens #76243) #145201

Summary

Every Hermes profile connected to Buzz Desktop as a custom ACP harness (hermes -p <profile> acp) can still receive Buzz messages, but no longer replies in the channel or DM. The agent writes a reply, runs buzz messages send as the Buzz base prompt instructs, and the CLI fails:

{"error":"auth_error","message":"auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)","retryable":false}

The same setup worked until the install moved to a build with the gateway attach model. The last working build we know of is d923a5eb48. It is broken on bf0203a794.

This looks like a regression of #76243, which was fixed by #78511 / #99433. That fix passes BUZZ_* to terminal children only when _buzz_terminal_context_active() is true:

• BUZZ_MANAGED_AGENT is in the process env, or
• HERMES_SESSION_PLATFORM == "buzz".

Under the attach model, neither condition holds in the process that actually runs the tools.

Environment

• macOS 27.0.1
• Hermes Agent: hermes acp --version = 0.22.5, checkout bf0203a794a07aac3ff764972ab9087baa4e4f4e (2026-10-22)
• Buzz Desktop v0.5.28. The agent uses a custom harness: command ~/.hermes/hermes-agent/.hermes/bin/hermes, args -p sb-librarian acp, no extra env vars.
• One host gateway (multiplexed) serves all local profiles. Hermes Desktop started it via hermes gateway ensure.

Steps to reproduce

1. In Buzz Desktop, add a custom harness that runs hermes -p <profile> acp, and attach a Buzz agent to it.
2. Make sure the host Hermes gateway is already running. Opening Hermes Desktop is enough.
3. @mention the agent in a Buzz channel or DM.

Expected

The agent's terminal tool gets the harness-provided BUZZ_PRIVATE_KEY / BUZZ_RELAY_URL / BUZZ_AUTH_TAG, so buzz messages send succeeds. This is the behaviour #99433 restored.

Actual

• The prompt arrives and the turn runs. The gateway log shows gateway.run: inbound message: platform=local ... and agent.turn_context: ... platform=acp.
• In the agent's terminal tool, env | grep '^BUZZ' returns nothing.
• buzz messages send exits with code 3 (auth_error), so the reply never reaches Buzz.

Timeline on the affected host

• 2026-10-16 12:07: Hermes checked out at d923a5eb48.
• 2026-10-16 12:22: last successful Buzz reply. The session store records it as source acp (in-process). buzz messages send returned "accepted":true.
• 2026-10-25 10:12: Hermes checked out at bf0203a794.
• 2026-10-25 10:13: Hermes Desktop starts the host gateway.
• 2026-10-25 13:45 onward: every Buzz turn is stored as source local (routed through the gateway) and every send fails with auth_error. Seen on two profiles so far (sb-librarian, profile-b); the owner reports that every Buzz-connected profile has stopped replying.
• The OS upgrade to macOS 27.0.1 on 2026-10-09 is not the cause: replies were still succeeding on 2026-10-16.

Evidence (names only, no values)

• ps eww on the Buzz buzz-acp processes shows BUZZ_PRIVATE_KEY, BUZZ_RELAY_URL, BUZZ_AUTH_TAG and BUZZ_MANAGED_AGENT all present. Buzz hands them over as designed.
• The host gateway process (started by Hermes Desktop via osascript → hermes ... gateway run --external-supervisor) has no BUZZ_* variables.
• acp_adapter/gateway_server.py: "ACP projection of the profile gateway; never constructs an execution owner." acp_adapter/entry.py: "MCP discovery and execution belong to the gateway daemon; this process is a viewer." Tools run in the gateway, not in the process the harness spawned.
• In tools/environments/local_env_policy.py, _buzz_terminal_context_active() checks os.environ.get("BUZZ_MANAGED_AGENT") in the gateway process, which is false, and the session platform, which is acp/local rather than buzz. The carve-out therefore never activates.
• terminal.env_passthrough is no workaround: BUZZ_* names are refused there by design (GHSA-rhgp-j443-p4rf).

Why the obvious workarounds don't fit

• gateway.standalone: true is unlikely to help (not tested). The ACP process is still a viewer of whichever gateway is serving the profile, and that gateway gets the harness env only if the harness happened to start it. The flag is also documented as a temporary shim.
• Pinning to a pre-attach-model build would likely work (not tested), but means giving up current fixes.

Suggested fix directions (for maintainers to decide)

1. The ACP viewer forwards the harness-provided BUZZ_* values (and BUZZ_MANAGED_AGENT) to the gateway as session-scoped credentials when it attaches or submits. The gateway then injects them only into that session's terminal children. This keeps the existing scope rule: no other session or profile sees them.
2. Alternatively, tag the session as Buzz-managed at attach time so _buzz_terminal_context_active() is true for that session only, with the values held in a per-session secret scope rather than the gateway's process env.

Related

• Buzz Desktop managed Hermes agent wakes but cannot reply because BUZZ_PRIVATE_KEY is stripped #76243 (original issue), fix(terminal): let Buzz-managed agents inherit the BUZZ CLI credentials the harness hands them #78511, fix(terminal): Buzz agents can use the buzz CLI from the terminal — credentials pass to their children only (salvages #78065 #78511) #99433 (fix)
• [Bug] Hermes agent does not work out of the box — managed session missing BUZZ_PRIVATE_KEY and BUZZ_RELAY_URL block/buzz#3768, buzz-acp: hermes-agent ACP turns complete successfully but reply never publishes to the channel block/buzz#4923 (same symptom, reported on the Buzz side)