[Bug] Hermes agent does not work out of the box — managed session missing BUZZ_PRIVATE_KEY and BUZZ_RELAY_URL

[suhaskashyaps]

Description

Setting up a Hermes agent through Buzz does not work out of the box. Delivery is blocked immediately after setup with no manual configuration errors on my side.

Environment

I am running the Hermes agent setup on a VPS (headless, self-managed server), and this is where it is not working. There is no desktop app in the loop on that machine, so if credential provisioning only happens through the desktop flow, headless/VPS setups are left with no working path.

Error message

Buzz delivery is currently blocked because the managed session is missing BUZZ_PRIVATE_KEY and BUZZ_RELAY_URL; the CLI returned an authentication error.

Expected behavior

A managed Hermes agent session should be provisioned with BUZZ_PRIVATE_KEY and BUZZ_RELAY_URL automatically, the same way other managed harness sessions receive their delivery credentials. No manual env injection should be required for the default flow.

Actual behavior

The managed session spawns without those two variables, the CLI fails with an authentication error, and all Buzz delivery from the agent is blocked.

Possibly related

• Hermes Harness option removed. #3582 (Hermes harness option removed)
• [Bug] Custom/BYOH ACP harness receives no authenticated Buzz reply tool, so completed turns cannot post #3385 (Custom/BYOH ACP harness receives no authenticated Buzz reply tool)

Happy to provide harness logs or agent config if useful.

[suhaskashyaps]

Harness logs from the failing setup (sanitized: pubkeys truncated, relay domain and home directory redacted; repeated per-agent init blocks collapsed).

Key line — the agent's own buzz CLI call inside the session fails because the env var was never provisioned:

[WARNING] agent.tool_executor: Tool terminal returned error (0.02s): {"output": "{\"error\":\"auth_error\",\"message\":\"auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)\",\"retryable\":false}", "exit_code": 3, "error": null}

Full log:

2026-07-30T17:04:22.233330Z  INFO buzz_acp: agent initialized: {"agentCapabilities":{"loadSession":true,"promptCapabilities":{"image":true},"sessionCapabilities":{"fork":{},"list":{},"resume":{}}},"agentInfo":{"name":"hermes-agent","version":"0.19.0"},"authMethods":[{"description":"Authenticate Hermes using the currently configured openai-codex runtime credentials.","id":"openai-codex","name":"openai-codex runtime credentials"},{"args":["--setup"],"description":"Open Hermes' interactive model/provider setup in a terminal. Use this when Hermes has not been configured on this machine yet.","id":"hermes-setup","name":"Configure Hermes provider","type":"terminal"}],"protocolVersion":1} agent=9
2026-07-30T17:04:22.233349Z  INFO buzz_acp: agent initialized agent=9 name="hermes-agent" steering_supported=false
2026-07-30T17:04:22.233362Z  INFO buzz_acp: agent_pool_ready agents=10
2026-07-30T17:04:22.384063Z  INFO buzz_acp: connected to relay at wss://[redacted-relay]
2026-07-30T17:04:22.384106Z  INFO buzz_acp: subscribed to membership notifications
2026-07-30T17:04:22.384170Z  INFO buzz_acp: owner resolved from BUZZ_AUTH_TAG: 65d2495a…[truncated]
2026-07-30T17:04:22.384174Z  INFO buzz_acp: agent owner: 65d2495a…[truncated]
2026-07-30T17:04:22.384194Z  INFO buzz_acp: relay observer enabled
2026-07-30T17:04:22.473481Z  INFO buzz_acp: discovered 0 channel(s)
2026-07-30T17:04:22.473513Z  WARN buzz_acp: no channel subscriptions resolved — agent will sit idle
2026-07-30T17:04:22.473563Z  INFO buzz_acp: presence set to online
2026-07-30T17:04:24.724637Z  INFO buzz_acp: shutting down
2026-07-30T17:04:24.724680Z  INFO buzz_acp: shutdown: waiting for in-flight prompts
2026-07-30T17:04:24.737175Z  INFO buzz_acp: presence set to offline
2026-07-30T17:04:24.737323Z  INFO buzz_acp: buzz-acp stopped
=== stopped PA (e83cc5fd…[truncated]) at 2026-07-30T17:04:25.760083+00:00 ===

=== starting PA (e83cc5fd…[truncated]) at 2026-07-30T17:04:25.785691+00:00 ===
2026-07-30T17:04:25.790441Z  INFO buzz_acp: buzz-acp starting: relay=wss://[redacted-relay] pubkey=e83cc5fd…[truncated] agent_cmd=~/.local/bin/hermes-acp  mcp_cmd= idle_timeout=900s max_turn=7200s agents=10 heartbeat=0s subscribe=Mentions dedup=Queue meh=Steer ignore_self=true context_limit=12 max_turns_per_session=0 presence=true typing=true memory=true model=openai-codex:gpt-5.6-sol permission_mode=bypassPermissions respond_to=owner-only
2026-07-30 22:34:26 [INFO] acp_adapter.entry: Loaded env from ~/.hermes/.env
2026-07-30 22:34:26 [INFO] acp_adapter.entry: Starting hermes-agent ACP adapter
2026-07-30 22:34:26 [INFO] acp_adapter.server: ACP client connected
2026-07-30 22:34:26 [INFO] acp_adapter.server: Initialize from buzz-acp (protocol v2)
2026-07-30T17:04:26.102123Z  INFO buzz_acp: agent initialized agent=0 name="hermes-agent" steering_supported=false

[... identical init/connect blocks repeated for agents 1-9, omitted ...]

2026-07-30T17:04:28.786513Z  INFO buzz_acp: agent_pool_ready agents=10
2026-07-30T17:04:28.965871Z  INFO buzz_acp: connected to relay at wss://[redacted-relay]
2026-07-30T17:04:28.965907Z  INFO buzz_acp: subscribed to membership notifications
2026-07-30T17:04:28.965970Z  INFO buzz_acp: owner resolved from BUZZ_AUTH_TAG: 65d2495a…[truncated]
2026-07-30T17:04:28.965976Z  INFO buzz_acp: agent owner: 65d2495a…[truncated]
2026-07-30T17:04:28.965981Z  INFO buzz_acp: relay observer enabled
2026-07-30T17:04:29.058938Z  INFO buzz_acp: discovered 0 channel(s)
2026-07-30T17:04:29.058982Z  WARN buzz_acp: no channel subscriptions resolved — agent will sit idle
2026-07-30T17:04:29.059031Z  INFO buzz_acp: presence set to online
2026-07-30T17:04:31.270803Z  INFO buzz_acp: membership notification: subscribing to new channel channel_id=9886a768-be8c-400c-b602-59003d5d9846
2026-07-30 22:34:37 [INFO] run_agent: Loaded environment variables from ~/.hermes/.env
2026-07-30 22:34:37 [INFO] run_agent: OpenAI client created (agent_init, shared=True) thread=MainThread:8553577280 provider=openai-codex base_url=https://chatgpt.com/backend-api/codex model=gpt-5.6-sol
2026-07-30 22:34:37 [WARNING] tools.registry: check_fn check_browser_requirements returned False; dependent tools will be unavailable this turn
2026-07-30 22:34:37 [WARNING] tools.registry: check_fn _browser_cdp_check returned False; dependent tools will be unavailable this turn
2026-07-30 22:34:37 [WARNING] tools.registry: check_fn _browser_dialog_check returned False; dependent tools will be unavailable this turn
2026-07-30 22:34:37 [WARNING] tools.registry: check_fn check_browser_vision_requirements returned False; dependent tools will be unavailable this turn
2026-07-30 22:34:37 [INFO] acp_adapter.session: Created ACP session 6bf7a41e-08e3-4850-93de-48139bd3d530 (cwd=~/.buzz)
2026-07-30 22:34:37 [INFO] acp_adapter.server: New session 6bf7a41e-08e3-4850-93de-48139bd3d530 (cwd=~/.buzz)
2026-07-30 22:34:39 [INFO] acp_adapter.server: Session 6bf7a41e-08e3-4850-93de-48139bd3d530: model switched to gpt-5.6-sol via provider openai-codex
2026-07-30 22:34:39 [INFO] acp_adapter.server: Prompt on session 6bf7a41e-08e3-4850-93de-48139bd3d530: [Base]
You are operating inside the Buzz platform — a Nostr-based messaging platform for human-agent
2026-07-30 22:34:39 [INFO] agent.turn_context: conversation turn: session=6bf7a41e-08e3-4850-93de-48139bd3d530 model=gpt-5.6-sol provider=openai-codex platform=acp history=0 msg='[Base] You are operating inside the Buzz platform — a Nostr-based messaging plat...'
2026-07-30 22:34:44 [INFO] agent.conversation_loop: API call #1: model=gpt-5.6-sol provider=openai-codex in=18857 out=113 total=18970 latency=4.5s
2026-07-30 22:34:44 [INFO] tools.terminal_tool: Creating new local environment for task default...
2026-07-30 22:34:44 [INFO] tools.environments.base: Session snapshot created (session=7fbb9607288a, cwd=~/.buzz)
2026-07-30 22:34:44 [INFO] tools.terminal_tool: local environment ready for task default
2026-07-30 22:34:44 [INFO] agent.tool_executor: tool terminal completed (0.09s, 1108 chars)
2026-07-30 22:34:49 [INFO] agent.conversation_loop: API call #2: model=gpt-5.6-sol provider=openai-codex in=19259 out=174 total=19433 latency=5.7s cache=17920/19259 (93%)
2026-07-30 22:34:49 [WARNING] agent.tool_executor: Tool terminal returned error (0.02s): {"output": "{\"error\":\"auth_error\",\"message\":\"auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)\",\"retryable\":false}", "exit_code": 3, "error": null}
2026-07-30 22:34:58 [INFO] agent.conversation_loop: API call #3: model=gpt-5.6-sol provider=openai-codex in=19500 out=253 total=19753 latency=8.5s cache=18944/19500 (97%)
2026-07-30 22:34:58 [INFO] agent.conversation_loop: Turn ended: reason=text_response(finish_reason=stop) model=gpt-5.6-sol api_calls=3/90 budget=3/90 tool_turns=2 last_msg_role=assistant response_len=213 session=6bf7a41e-08e3-4850-93de-48139bd3d530
2026-07-30 22:34:58 [INFO] agent.auxiliary_client: Auxiliary title_generation: using openai-codex (gpt-5.5) at https://chatgpt.com/backend-api/codex/
2026-07-30 22:35:49 [INFO] acp_adapter.server: Prompt on session 6bf7a41e-08e3-4850-93de-48139bd3d530: [Base]
You are operating inside the Buzz platform — a Nostr-based messaging platform for human-agent
2026-07-30 22:35:49 [INFO] agent.turn_context: conversation turn: session=6bf7a41e-08e3-4850-93de-48139bd3d530 model=gpt-5.6-sol provider=openai-codex platform=acp history=6 msg='[Base] You are operating inside the Buzz platform — a Nostr-based messaging plat...'
2026-07-30 22:35:53 [INFO] agent.conversation_loop: API call #4: model=gpt-5.6-sol provider=openai-codex in=23626 out=146 total=23772 latency=4.1s cache=18944/23626 (80%)
2026-07-30 22:35:53 [WARNING] agent.tool_executor: Tool terminal returned error (0.04s): {"output": "{\"error\":\"auth_error\",\"message\":\"auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)\",\"retryable\":false}", "exit_code": 3, "error": null}
2026-07-30 22:35:56 [INFO] agent.conversation_loop: API call #5: model=gpt-5.6-sol provider=openai-codex in=23839 out=64 total=23903 latency=3.2s cache=23040/23839 (97%)
2026-07-30 22:35:56 [INFO] agent.conversation_loop: Turn ended: reason=text_response(finish_reason=stop) model=gpt-5.6-sol api_calls=2/90 budget=2/90 tool_turns=3 last_msg_role=assistant response_len=214 session=6bf7a41e-08e3-4850-93de-48139bd3d530

Observations from the log:

• buzz-acp itself connects to the relay fine (its own key works), and the hermes-agent ACP adapter initializes and takes prompts normally.
• The failure is inside the agent session: when the agent runs the buzz CLI via its terminal tool to deliver a reply, the spawned environment has no BUZZ_PRIVATE_KEY, so every delivery attempt exits with auth_error (exit code 3) and the turn's reply is lost.
• So the credentials exist at the buzz-acp layer but are not passed through to the managed Hermes session's environment.

[jamesjlopez]

Additional Desktop reproduction (Buzz 0.5.4)

This same failure occurs in the macOS Desktop managed-agent path, not only in headless/VPS Hermes setups.

Expected contract

The trusted Desktop managed-agent spawn path should hydrate the agent identity from the macOS Keychain and inject the canonical values into the managed buzz-acp process:

• BUZZ_PRIVATE_KEY
• BUZZ_RELAY_URL
• BUZZ_AUTH_TAG only when the owner-attestation record provides it

The source contract is in desktop/src-tauri/src/managed_agents/runtime.rs; the credential names are reserved from user/persona environment overrides.

Actual behavior

On macOS with Buzz Desktop 0.5.4, the managed Jarvis ACP session starts and can receive relay events, but its tool environment lacks BUZZ_PRIVATE_KEY. Running the bundled buzz CLI from the session fails with:

error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)

BUZZ_RELAY_URL and BUZZ_PRIVATE_KEY are present in the user's launch environment, but restarting Buzz does not make the managed session receive the private key. The agent record has no inline private key, which is expected only if Desktop successfully hydrates it from Keychain before spawn.

Suggested investigation

Please trace the Desktop managed-agent record hydration and spawn path for records whose private key is stored in Keychain rather than inline. If Keychain lookup fails, the secure behavior should be to refuse to spawn the unauthenticated child with a clear error, not to start it without BUZZ_PRIVATE_KEY.

This is not a request for generic environment passthrough. User/persona/launchctl values should remain unable to forge or replace the Desktop-owned identity credentials, and BUZZ_AUTH_TAG should remain Desktop-controlled.

No secrets, private keys, auth tags, or managed-agent records are included here.

[jcg-git]

Confirming this reproduces on Buzz Desktop 0.5.6 too, so it's not specific to 0.5.4 — same exact failure signature as both reports above.

Setup

• Freshly created managed agent using the official "Hermes Agent" preset (agent_command: hermes-acp), not a stale/pre-existing instance — rules out "an old broken record" as the explanation.
• Sent a real test prompt via a Buzz DM.

Observed behavior

The session initializes and receives the prompt normally, runs real tool calls (shell commands) successfully, and composes a full, coherent reply — but self-reports it cannot deliver it:

The reply is written above, but I can't actually publish it — BUZZ_PRIVATE_KEY is not set in this environment. The buzz CLI returned an auth error (exit code 3). Until that env var is configured, I'm unable to send messages to the channel.

Matches the exact error class already reported: auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var).

No local workaround available

Looked into manually setting BUZZ_PRIVATE_KEY as a per-agent env var override (the same mechanism that works for other config, e.g. CODEX_CONFIG on a Codex-runtime agent) as a stopgap. Not viable here: Desktop's managed-agent credential storage bundles every managed agent's private key together in a single encrypted Keychain blob under one generic service name, with no per-agent reveal/export exposed anywhere in the UI. Extracting just one agent's key would mean decrypting and exposing the entire credential store (every other managed agent's key at once), which isn't a reasonable workaround for one broken agent. Worth noting as its own gap — even if the automatic hydration is fixed, there's currently no supported manual recovery path if it fails again.