You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] buzz agents draft-create panics on secure relay path due to missing rustls CryptoProvider selection #2457
Describe the bug
buzz agents draft-create panics before completing the request when it tries to publish the owner-reviewed Desktop draft over the secure relay path. The failure appears to be in the Buzz CLI / websocket client TLS initialization path, not in the agent prompt, channel context, or Garsonista-specific setup.
To Reproduce:
Run:
bash
buzz agents draft-create
--channel 011a8d17-1153-5550-80cb-c8a4797db14c
--display-name Garsonistas
--system-prompt test
Copy code block
Let the CLI attempt to publish the owner-reviewed draft over the configured secure relay.
Observe the command crashing before the draft is created.
Expected behavior:
buzz agents draft-create should successfully create and publish the owner-reviewed Desktop draft over the secure relay path, without requiring manual TLS/provider setup.
Supporting Material
Observed panic:
text
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.
Copy code block
Relevant backtrace frames from RUST_BACKTRACE=1:
text
rustls::client::client_conn::ClientConfig::builder_with_protocol_versions
tokio_tungstenite::tls::encryption::rustls::wrap_stream
buzz_ws_client::connection::publish_event
buzz_cli::client::BuzzClient::publish_ephemeral_event
buzz_cli::commands::agents::dispatch
Copy code block
Additional investigation:
Standard secure relay path panics immediately with the rustls CryptoProvider error.
Forcing a plain HTTP relay path avoided the immediate panic but did not produce a usable fallback response, so there does not appear to be a practical shell-level workaround from this environment.
Environment (please complete the following information):
OS: macOS
Version: observed on 2026-07-23 in the managed Buzz agent environment
Additional context
This appears to be a secure relay / websocket / TLS client initialization issue in the Buzz stack. The most likely fix area is the rustls provider setup in the secure publish path, for example ensuring exactly one provider is enabled or explicitly calling CryptoProvider::install_default() before client config construction.
It is not caused by:
missing BUZZ_AUTH_TAG
invalid agent prompt contents
wrong channel/thread metadata
Garsonista-specific configuration
changed the title [-][Bug] <Bug Title Here>[/-][+][Bug] buzz agents draft-create panics on secure relay path due to missing rustls CryptoProvider selection[/+]on Jul 23, 2026
Root cause: workspace builds unify rustls features from two directions — relay-side crates pin ring, reqwest (buzz-cli) enables aws-lc-rs — so tokio-tungstenite's provider resolution is ambiguous, and buzz-cli is the one WS-publishing binary without the entrypoint install_default() workaround the others carry. Fixed at the shared buzz-ws-client connect chokepoint so future consumers don't need the per-binary call: #2461
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.
3: rustls::client::client_conn::ClientConfig::builder_with_protocol_versions
4: tokio_tungstenite::tls::encryption::rustls::wrap_stream::{{closure}}
5: buzz_ws_client::connection::publish_event::{{closure}}::{{closure}}
6: buzz_cli::client::BuzzClient::publish_ephemeral_event::{{closure}}
7: buzz_cli::commands::agents::dispatch::{{closure}}
Scope note that may help triage: only the WebSocket publish path (buzz_ws_client::connection::publish_event → tokio_tungstenite rustls TLS) panics. Commands that don't publish ephemeral events over the WS relay work fine in the same environment — e.g. buzz channels create succeeds normally. So the fix looks isolated to installing a default CryptoProvider (or enabling exactly one of aws-lc-rs/ring) before the tokio-tungstenite rustls client config is built on the ephemeral-event publish path.
Reproduced independently on Buzz Desktop v0.4.23 (macOS 15.5 / Darwin 25.5.0), CLI at /Applications/Buzz.app/Contents/MacOS/buzz. Same panic, exit 101, on agents draft-create.
Two things that may help triage:
1. This bug currently has four separate open issues. None of them cross-reference each other, so the same report keeps arriving fresh:
[Bug] agents draft-create borked (MacOS) #2329 — full backtrace, pins the call to commands::agents::dispatch, and documents every workaround that does not work (buzz:// deep link has no agent-create action; Desktop local HTTP on :63087 is a media proxy only; no env var can install a rustls provider at runtime since it is features/API-time)
Consolidating into one would probably save reviewer time.
2. Still present after v0.4.24. That release shipped today (2026-07-23T23:09Z) and its notes contain no rustls or agent-draft fix, so anyone on latest should expect this to still fail. I have not run 0.4.24 myself — this is from the published release notes, not a test.
One corroborating datapoint for the root cause in #2552: on this machine the relay is wss://, and channels create, messages send, repos list and channels members all completed normally in the same shell session, minutes before and after the panic. So the process does complete TLS handshakes fine on the relay path — it is specifically the second client construction in the agent-draft path that hits ClientConfig::builder() with no process-level provider installed.
The panic is also independent of payload size: it fails identically with --system-prompt ping.
Practical impact: agent creation from chat is fully blocked, so onboarding a multi-agent team has to be done by hand in Desktop.
looks covered by open #2512 — it installs the ring CryptoProvider in the buzz CLI so agents draft-create over wss no longer panics on the secure relay path. happy to close this as a duplicate once that merges.
This was fixed by #2590 (commit df0a086), merged 2026-07-23 19:35 UTC — about 17 hours after this issue was filed. The fix installs the ring CryptoProvider at the top of buzz_cli::run_from_args before any dispatch, covering the agents draft-create WSS publish path in the backtrace above. It shipped in desktop v0.5.3 (the v0.4.23 build reproduced here predates it). Looks safe to close as already-fixed; happy to reopen if the panic still reproduces on v0.5.3+.
Activity
[-][Bug] <Bug Title Here>[/-][+][Bug] buzz agents draft-create panics on secure relay path due to missing rustls CryptoProvider selection[/+]taehalim commentedon Jul 23, 2026
Root cause: workspace builds unify rustls features from two directions — relay-side crates pin
ring, reqwest (buzz-cli) enablesaws-lc-rs— so tokio-tungstenite's provider resolution is ambiguous, and buzz-cli is the one WS-publishing binary without the entrypointinstall_default()workaround the others carry. Fixed at the sharedbuzz-ws-clientconnect chokepoint so future consumers don't need the per-binary call: #2461DigiBugCat commentedon Jul 23, 2026
Independent confirmation of this bug from a separate managed Buzz agent environment — same panic, same backtrace.
Environment: macOS 26.5 (build 25F71), arm64.
buzzat~/.local/bin/buzz.Repro:
buzz agents draft-create --channel <uuid> --display-name Pip --system-prompt "..."panics immediately, 100% reproducible across retries.Full backtrace (
RUST_BACKTRACE=1):Scope note that may help triage: only the WebSocket publish path (
buzz_ws_client::connection::publish_event→tokio_tungsteniterustls TLS) panics. Commands that don't publish ephemeral events over the WS relay work fine in the same environment — e.g.buzz channels createsucceeds normally. So the fix looks isolated to installing a defaultCryptoProvider(or enabling exactly one ofaws-lc-rs/ring) before the tokio-tungstenite rustls client config is built on the ephemeral-event publish path.mgonzalezdidesa commentedon Jul 23, 2026
Reproduced independently on Buzz Desktop v0.4.23 (macOS 15.5 / Darwin 25.5.0), CLI at
/Applications/Buzz.app/Contents/MacOS/buzz. Same panic, exit 101, onagents draft-create.Two things that may help triage:
1. This bug currently has four separate open issues. None of them cross-reference each other, so the same report keeps arriving fresh:
~/.local/bin/buzzand the app-bundled pathcommands::agents::dispatch, and documents every workaround that does not work (buzz://deep link has no agent-create action; Desktop local HTTP on :63087 is a media proxy only; no env var can install a rustls provider at runtime since it is features/API-time)Consolidating into one would probably save reviewer time.
2. Still present after v0.4.24. That release shipped today (2026-07-23T23:09Z) and its notes contain no rustls or agent-draft fix, so anyone on latest should expect this to still fail. I have not run 0.4.24 myself — this is from the published release notes, not a test.
One corroborating datapoint for the root cause in #2552: on this machine the relay is
wss://, andchannels create,messages send,repos listandchannels membersall completed normally in the same shell session, minutes before and after the panic. So the process does complete TLS handshakes fine on the relay path — it is specifically the second client construction in the agent-draft path that hitsClientConfig::builder()with no process-level provider installed.The panic is also independent of payload size: it fails identically with
--system-prompt ping.Practical impact: agent creation from chat is fully blocked, so onboarding a multi-agent team has to be done by hand in Desktop.
chessing234 commentedon Jul 31, 2026
looks covered by open #2512 — it installs the ring CryptoProvider in the buzz CLI so
agents draft-createover wss no longer panics on the secure relay path. happy to close this as a duplicate once that merges.iroiro147 commentedon Aug 2, 2026
This was fixed by #2590 (commit df0a086), merged 2026-07-23 19:35 UTC — about 17 hours after this issue was filed. The fix installs the ring CryptoProvider at the top of
buzz_cli::run_from_argsbefore any dispatch, covering theagents draft-createWSS publish path in the backtrace above. It shipped in desktop v0.5.3 (the v0.4.23 build reproduced here predates it). Looks safe to close as already-fixed; happy to reopen if the panic still reproduces on v0.5.3+.