Repository navigation
buzz-cli panics on agents draft-create because rustls CryptoProvider is not installed #2308
Description
Summary
buzz agents draft-create panics before it can publish the owner-reviewed draft when the CLI opens its WebSocket/TLS path. The failure is a rustls process-level CryptoProvider panic, not an auth or relay rejection.
This reproduced with both:
buzz agents draft-create ...when~/.local/bin/buzzpointed at the app-bundled CLI/Applications/Buzz.app/Contents/MacOS/buzz agents draft-create ...
Reproduction
Run a draft create against a wss:// relay with BUZZ_RELAY_URL, BUZZ_PRIVATE_KEY, and BUZZ_AUTH_TAG set:
printf 'You are Hive Lead, the ambient coordinator for this Buzz workspace.' \
| RUST_BACKTRACE=1 buzz agents draft-create \
--channel 9a491620-9b72-4001-a4be-96dbb5cb364f \
--display-name 'Hive Lead' \
--system-prompt -Observed
The command panics before the draft event is published:
thread 'main' panicked at .../rustls-0.23.42/src/crypto/mod.rs:249:14:
Could not automatically determine the process-level CryptoProvider from Rustls crate features.
Call CryptoProvider::install_default() before this point to select a provider manually, or make sure exactly one of the 'aws-lc-rs' and 'ring' features is enabled.
Relevant backtrace frames:
rustls::client::client_conn::ClientConfig::builder_with_protocol_versions
tokio_tungstenite::tls::encryption::rustls::wrap_stream::{{closure}}
buzz_ws_client::connection::publish_event::{{closure}}::{{closure}}
buzz_cli::client::BuzzClient::publish_ephemeral_event::{{closure}}
buzz_cli::commands::agents::dispatch::{{closure}}
Expected
The CLI should publish the owner-reviewed draft request and return the normal draft-create JSON response instead of panicking.
Root Cause
buzz-cli reaches buzz-ws-client / tokio-tungstenite for ephemeral event publishing, but the CLI binary does not install a rustls crypto provider at startup. The workspace dependency graph includes both ring and aws-lc-rs transitively, so rustls cannot auto-select a provider.
Other binaries already handle this explicitly, for example buzz-relay, buzz-admin, buzz-acp, and test clients install a rustls provider before TLS use. buzz-cli appears to have missed the same startup initialization.
Local Fix Prepared
Local checkout branch: fix/buzz-cli-rustls-provider
Local commit: 8990138ca4ad04f122699909bc1d3aa523a27bb9 (fix: install rustls provider for buzz cli)
Patch shape:
- Add
rustls = { version = "0.23", default-features = false, features = ["ring", "std"] }as a directbuzz-clidependency. - Install the ring provider at
crates/buzz-cli/src/main.rsstartup beforerun_from_args:
let _ = rustls::crypto::ring::default_provider().install_default();Validation From Local Fix
After building the patched CLI, the original Hive Lead draft command succeeded:
{
"accepted": true,
"action": "create",
"event_id": "1f04ab472cfae1eea58d5a07864ce76370779e4f17d361fd6fe06bf04f074f99",
"message": "Draft sent to Buzz Desktop for owner review. Nothing changes until the owner saves it.",
"request_id": "9391b2c4-7995-4255-afc1-10fa576c4a5d",
"saved": false
}Local checks passed at commit 8990138ca4ad04f122699909bc1d3aa523a27bb9:
cargo fmt -p buzz-cli -- --checkcargo build -p buzz-clicargo test -p buzz-cli(250 passed)cargo clippy -p buzz-cli -- -D warnings
Release Follow-Up
The fix needs to ship in the desktop app bundle because /Applications/Buzz.app/Contents/MacOS/buzz still contains the panicking CLI until replaced by a build with this provider initialization. Other buzz-cli commands using the same WebSocket-only ephemeral publish path may be affected too.
Activity
thecombatwombat commentedon Jul 21, 2026
Additional triage detail from the failing local install:
xyz.block.buzz.app0.4.220.4.22/Applications/Buzz.app/Contents/MacOS/buzzbuzzCLIs reject--version, so the app bundle metadata above is the exact available build identifier.I attempted to add the
buglabel after filing, but the GitHub App integration returned403 Resource not accessible by integrationfor label mutation. The issue still needs a maintainer or a token with label-write permission to applybug/ CLI labels.BradGroux commentedon Jul 22, 2026
Independent reproduction from
BradGroux:0.4.2226.5.2on arm64~/.local/bin/buzzbuzz agents draft-createcalls all panicked with the reported CryptoProvider failurebuzz messages sendsucceeded in the same environment, so general relay connectivity and auth were healthyImpact: this blocks onboarding an existing seven-agent OpenClaw roster into Buzz Desktop through the owner-reviewed draft flow.
BradGroux commentedon Jul 22, 2026
Follow-up field reproduction (sanitized):
0.4.22on macOS arm64.buzz agents draft-createattempt reproduced the same rustlsCryptoProviderpanic. This was not part of the earlier seven-agent batch documented above.~/.local/bin/buzzand/Applications/Buzz.app/Contents/MacOS/buzzreached the same bundled binary and failure.buzz messages sendcontinued to work in the same environment.Client name, channel ID, agent name, system prompt, relay details, and auth material are intentionally omitted. This confirms #2308 blocks normal one-at-a-time agent creation, not only batch onboarding. A source merge must also reach a Desktop release containing the rebuilt bundled CLI before affected installations are fixed.
chessing234 commentedon Jul 23, 2026
Fixed in #2512 — buzz CLI installs rustls CryptoProvider at startup.
oveddan commentedon Jul 23, 2026
Same panic also hits
buzz agents draft-update(not just draft-create): exit 101,rustls-0.23.42/src/crypto/mod.rs:249— "Could not automatically determine the process-level CryptoProvider". Reproduced twice on macOS (Darwin 24.6.0), 2026-07-23, while trying to open a model-change draft. Other CLI commands (messages send, mem set) work fine in the same session, so it looks specific to the agents draft code path.docs(agents): add Review-Proven Rule 9, design client paths for the w…