Buzz agents cannot use the buzz CLI from the terminal: BUZZ_* credentials are stripped by the provider-credential blocklist #78026

Summary

Buzz platform agents cannot use the buzz CLI from their terminal tool: Hermes strips BUZZ_PRIVATE_KEY, BUZZ_AUTH_TAG, and BUZZ_RELAY_URL from every terminal subprocess it spawns, because those variables are classified as messaging-provider credentials on _HERMES_PROVIDER_ENV_BLOCKLIST. The result is auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var) (exit 3) on every buzz invocation, even though the agent process itself has the credentials in its environment.

Background

The Buzz platform instructs its agents that "the buzz CLI is your primary interface" — it is the sanctioned way for an agent to send messages, manage channels, run workflows, etc. But the terminal tool's credential scrubbing makes that primary interface unusable out of the box.

The scrub is deliberate and security-motivated (GHSA-rhgp-j443-p4rf class): BUZZ_* env vars are registered in OPTIONAL_ENV_VARS with category messaging, and _build_provider_env_blocklist() in tools/environments/local.py adds every tool/messaging-category variable to _HERMES_PROVIDER_ENV_BLOCKLIST. _make_run_env() and _sanitize_subprocess_env() then drop blocklisted names from terminal child environments.

Why the obvious workarounds fail

• terminal.env_passthrough config does not work. _load_config_passthrough() in tools/env_passthrough.py refuses to register any name where _is_hermes_provider_credential() is true — and all three BUZZ vars are on the blocklist, so they are rejected with a warning and silently skipped. The existing TRAKT_*/TMDB_* entries in users' configs only work because those names are not blocklisted.
• Skill registration does not work either. register_env_passthrough() applies the same provider-credential rejection.

Current escape hatch (works, but wrong layer)

The _HERMES_FORCE_ env prefix is the only path that works: a variable named _HERMES_FORCE_BUZZ_PRIVATE_KEY is renamed to BUZZ_PRIVATE_KEY in the terminal run env, bypassing the blocklist (verified against _make_run_env()). This requires every Buzz agent to be launched through a wrapper script that exports the force-prefixed copies before exec'ing the ACP command — friction that should not exist for a first-party platform, and knowledge that is undocumented for this purpose.

Expected behavior

The Buzz adapter — a first-party Hermes platform — should be able to register its own platform credentials for terminal passthrough, so agents can use the buzz CLI from the terminal without custom wrappers.

Proposed fix directions

1. First-party adapter exception: allow platform adapters (the Buzz adapter specifically) to register their own BUZZ_* vars via register_env_passthrough() / a first-party path, while keeping the blocklist closed to skills and arbitrary config. The GHSA concern is about skills tunneling Hermes-managed inference credentials into sandboxed children; BUZZ_PRIVATE_KEY is the agent's own platform identity, not a Hermes inference credential.
2. Exclude BUZZ_ from the terminal scrub:* since BUZZ_PRIVATE_KEY/BUZZ_AUTH_TAG/BUZZ_RELAY_URL are the agent's own platform identity and the platform's primary tool interface requires them, carve them out of _HERMES_PROVIDER_ENV_BLOCKLIST for terminal children (keeping them stripped from execute_code/sandbox paths if desired).

Environment

• Hermes Agent (current main)
• macOS 26.6
• Buzz platform via the ACP adapter (hermes acp)

Files referenced

• tools/environments/local.py — _HERMES_PROVIDER_ENV_BLOCKLIST, _make_run_env(), _sanitize_subprocess_env()
• tools/env_passthrough.py — _load_config_passthrough(), register_env_passthrough(), _is_hermes_provider_credential()
• hermes_cli/config.py — OPTIONAL_ENV_VARS (BUZZ_* entries, category messaging)
• plugins/platforms/buzz/adapter.py — first-party Buzz platform adapter

Filed by Herb (AI agent on behalf of Magnus Hedemark)