buzz-cli panics on agents draft-create because rustls CryptoProvider is not installed

[thecombatwombat]

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/buzz pointed 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 direct buzz-cli dependency.
• Install the ring provider at crates/buzz-cli/src/main.rs startup before run_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 -- --check
• cargo build -p buzz-cli
• cargo 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.

[thecombatwombat]

Additional triage detail from the failing local install:

• Desktop bundle identifier: xyz.block.buzz.app
• Desktop app version: 0.4.22
• Desktop bundle build: 0.4.22
• Failing bundled CLI path: /Applications/Buzz.app/Contents/MacOS/buzz
• CLI version flag note: both the bundled and patched buzz CLIs reject --version, so the app bundle metadata above is the exact available build identifier.

I attempted to add the bug label after filing, but the GitHub App integration returned 403 Resource not accessible by integration for label mutation. The issue still needs a maintainer or a token with label-write permission to apply bug / CLI labels.

[BradGroux]

Independent reproduction from BradGroux:

• Buzz Desktop 0.4.22
• macOS 26.5.2 on arm64
• App-bundled CLI via ~/.local/bin/buzz
• Authenticated remote WSS relay
• Seven parallel buzz agents draft-create calls all panicked with the reported CryptoProvider failure
• One sequential retry panicked identically, ruling out invocation concurrency as the trigger
• buzz messages send succeeded in the same environment, so general relay connectivity and auth were healthy
• No draft events were created

Impact: this blocks onboarding an existing seven-agent OpenClaw roster into Buzz Desktop through the owner-reviewed draft flow.

[BradGroux]

Follow-up field reproduction (sanitized):

• Buzz Desktop 0.4.22 on macOS arm64.
• A separate ordinary, single-agent buzz agents draft-create attempt reproduced the same rustls CryptoProvider panic. This was not part of the earlier seven-agent batch documented above.
• Both ~/.local/bin/buzz and /Applications/Buzz.app/Contents/MacOS/buzz reached the same bundled binary and failure.
• buzz messages send continued to work in the same environment.
• No owner-review draft event was published.

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]

Fixed in #2512 — buzz CLI installs rustls CryptoProvider at startup.

[oveddan]

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.