[Field report] Cross-platform release failures: relay-mesh capability mismatch, WSLg WebKit crashes, AppImage ABI error, Windows Defender quarantine

[fck007]

Executive summary

During an attempt to deploy Buzz for a small private engineering workspace, I reproduced several independent release/runtime problems across the official Linux and Windows artifacts:

1. The Buzz 0.5.0 Linux .deb appeared to expose relay-mesh configuration even though the packaged binary did not include the corresponding mesh-llm capability. The provider value was forwarded literally and all configured workers failed.
2. Buzz Desktop 0.5.0 and 0.5.1 repeatedly crashed under Ubuntu 24.04 on WSLg. The crash occurred near the end of agent responses and consistently ended in a WatchDogQueue int3 trap inside GLib/WebKitGTK.
3. The 0.5.1 AppImage enabled the DMABUF workaround but failed because of a bundled/system library ABI mismatch involving libcurl-gnutls, libnghttp2, and libgiolibproxy.
4. The latest 0.5.1 release had no Windows artifact, so the official 0.4.26 alpha unsigned Windows installer was tested. Microsoft Defender detected buzz-acp.exe as Trojan:Win32/Bearfoos.A!ml, quarantined it, and agent startup then failed with Windows error 2.
5. Before quarantine, one Claude Code agent configured with parallelism 1 produced 58 claude-agent-acp Node processes and remained indefinitely in repeated turn_liveness events despite the same Claude CLI succeeding directly.

This report does not claim the Defender detection is a true positive. It documents the exact observed behavior and requests signed artifacts, reproducible hashes/SBOM, release capability validation, and platform-specific regression coverage.

---

Environment

Windows host

• Windows build: 10.0.26200.8875
• GPU: NVIDIA GeForce GTX 1070 Ti, 8 GiB
• WSL before update:
  • WSL 2.1.5.0
  • kernel 5.15.146.1-2
  • WSLg 1.0.60
• WSL after update:
  • WSL 2.7.11.0
  • kernel 6.18.33.2-2
  • WSLg 1.0.73.2
• /dev/dxg existed.
• DISPLAY=:0
• WAYLAND_DISPLAY=wayland-0

Linux guest

• Ubuntu 24.04 under WSL2/WSLg
• Buzz tested:
  • 0.5.0 .deb
  • 0.5.1 .deb
  • 0.5.1 AppImage

Windows client

• Buzz 0.4.26_x64-setup_alpha-unsigned.exe
• Claude Code 2.1.220
• @agentclientprotocol/claude-agent-acp 0.63.0
• Codex CLI authenticated separately

No private keys, seeds, API tokens, or relay credentials are included.

---

1. Linux release capability mismatch: relay-mesh

Observed behavior

A managed agent was configured with:

provider = relay-mesh
model_ref = unsloth/gemma-4-E4B-it-GGUF:Q4_K_M
parallelism = 24

On Buzz 0.5.0 .deb, all 24 workers failed. Inspection of the installed binary showed that the release package did not contain the expected mesh capability/mapping, while the source implementation appeared gated behind the mesh-llm feature.

The effective provider string reached the runtime literally as relay-mesh instead of resolving to the mesh-backed provider.

Expected behavior

One of the following should happen:

1. Official artifacts that expose/select relay-mesh include the required feature; or
2. Desktop validates release capabilities and hides/rejects unsupported providers before spawning workers; or
3. Startup fails once with a clear message such as relay-mesh is unavailable in this build.

Actual impact

• 24 workers were spawned and failed.
• The UI exposed a configuration that the release artifact could not execute.
• Troubleshooting required source inspection and binary string inspection.

Suggested fixes

• Publish a machine-readable capability manifest with each artifact.
• Add startup validation for provider/runtime availability.
• Test the exact release binaries, not only source builds, in CI.
• Include enabled Cargo features in --version or a diagnostics screen.

---

2. Buzz Desktop crash on WSLg/WebKitGTK

Symptom

Buzz Desktop worked long enough to receive and render agent output, then closed abruptly, commonly near the end of the response. The agent/backend could continue processing while the desktop UI disappeared.

Stable crash signature

Kernel log:

traps: WatchDogQueue[...] trap int3 ... in libglib-2.0.so.0.8000.0

Desktop log:

WebProcess didn't exit as expected after the UI process connection was closed

Other recurring messages:

libEGL warning: DRI3 error: Could not get DRI3 device
libEGL warning: failed to open /dev/dri/renderD128: Permission denied
MESA: error: ZINK: failed to choose pdev
libEGL warning: egl: failed to create dri2 screen

OOM was ruled out

At the time of one crash:

Mem: 5.8 GiB total, 4.7 GiB available
Swap: 10 GiB total, 9.3 GiB available

No OOM kill was recorded.

Reproduction matrix

Configuration	Result
Buzz 0.5.0 .deb, default rendering	Crash
LIBGL_ALWAYS_SOFTWARE=1	Crash
WEBKIT_DISABLE_DMABUF_RENDERER=1	Crash
WEBKIT_SKIA_ENABLE_CPU_RENDERING=1	Crash
GDK_BACKEND=x11	Crash
WSL/WSLg upgraded to 2.7.11 / 1.0.73.2	Crash
Buzz 0.5.1 .deb	Crash

Important detail from 0.5.1 .deb

buzz-desktop: WebKit rendering left as-is — no NVIDIA GPU and not an AppImage

Under WSLg the host NVIDIA GPU is exposed through /dev/dxg, but the package did not classify the environment as NVIDIA and did not apply the AppImage workaround.

Suggested fixes

• Add a --safe-rendering flag that centrally applies tested WebKit/Skia fallbacks.
• Detect WSLg explicitly instead of relying on normal Linux GPU detection.
• Add WSLg to the Linux release smoke matrix.
• Capture and preserve WebKit/GLib crash diagnostics automatically.
• Consider isolating/restarting the renderer rather than terminating the full desktop.

Related issue neighborhood: #2338, #2643, #2960.

---

3. Buzz 0.5.1 AppImage ABI/library mismatch

The AppImage announced:

WEBKIT_DISABLE_DMABUF_RENDERER=1 — AppImage

It then failed with:

/lib/x86_64-linux-gnu/libcurl-gnutls.so.4:
undefined symbol:
nghttp2_option_set_no_rfc9113_leading_and_trailing_ws_validation

Failed to load module:
/usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so

Additional PipeWire/ALSA warnings were present, but the decisive failure was the symbol mismatch.

Suggested fixes

• Run the AppImage on Ubuntu 24.04 WSLg in release CI.
• Audit libcurl, libnghttp2, GIO modules, and loader search order.
• Publish the bundled dependency inventory.
• Add an AppImage self-diagnostic command that prints loaded library paths.

---

4. Windows artifact gap and Defender quarantine

Release gap

The 0.5.1 GitHub release exposed Linux AppImage, Linux .deb, and macOS .dmg, but no Windows artifact.

The latest available official Windows artifact found was:

Buzz_0.4.26_x64-setup_alpha-unsigned.exe

Defender result

Microsoft Defender detected:

Trojan:Win32/Bearfoos.A!ml

Affected file:

C:\Users\<user>\AppData\Local\Buzz\buzz-acp.exe

After Defender quarantined/removed the file, Buzz displayed:

failed to spawn ...\buzz-acp.exe
The system cannot find the file specified. (os error 2)

Security interpretation

This report does not determine whether the ML detection is a true positive or false positive.

However, for end users the practical result is the same:

• The official unsigned alpha artifact is blocked as a severe threat.
• Restoring/allowlisting the file is not a reasonable default recommendation.
• Agent functionality becomes unusable after quarantine.

Suggested fixes

• Publish signed Windows artifacts for current releases.
• Publish SHA-256 checksums and an SBOM.
• Document build provenance and reproducibility.
• Submit release binaries to Microsoft for analysis before publication.
• Add Defender/SmartScreen validation to release CI.
• Provide a known-false-positive note only after maintainers independently verify the binary.

---

5. Claude ACP process explosion and indefinite turn_liveness

Before Defender removed buzz-acp.exe, a single Bumble agent was configured as:

Agent harness: Claude Code
Model: haiku
Parallelism: 1
Environment variables: none
Who can talk: Only me

Buzz Raw ACP Activity accepted session/prompt and then emitted repeated:

turn_liveness

No final model response arrived.

At the same time:

claude-agent-acp version: 0.63.0
Claude Code version: 2.1.220
claude-agent-acp Node process count: 58

A direct non-interactive Claude test succeeded:

claude -p "Responda apenas: AUTH_OK" --output-format stream-json --verbose

Result:

AUTH_OK
subtype: success
terminal_reason: completed
provider: firstParty

Authentication confounder that was resolved

Earlier authentication failures were caused by user-level environment variables redirecting Claude Code to an external Anthropic-compatible gateway. After removing them, direct Claude authentication succeeded. Buzz still entered repeated turn_liveness and the adapter process count grew to 58.

Expected behavior

With parallelism 1, one agent should not produce dozens of adapter processes.

A failed child should:

• terminate cleanly,
• use bounded retries/backoff,
• expose the actual child stderr/exit code,
• avoid an indefinite liveness-only state.

Suggested fixes

• Enforce a hard upper bound derived from configured parallelism.
• Add deduplicated spawn ownership and child reaping on Windows.
• Surface child PID, command, exit code, stderr, and retry count in Raw ACP Activity.
• Add a circuit breaker for repeated spawn/session failures.
• Add a Windows integration test using current Claude Code and claude-agent-acp.

---

Combined impact

The full tested path had no stable supported endpoint:

• Linux .deb: UI crashes under WSLg.
• Linux AppImage: library ABI mismatch.
• relay-mesh: exposed but unavailable in the release binary tested.
• Windows current release: no artifact.
• Windows previous alpha artifact: Defender quarantines buzz-acp.exe.
• Windows ACP runtime: process explosion and indefinite liveness before quarantine.

The relay, community, channels, and identities themselves remained functional, but the team-agent workflow was not usable.

---

Requested maintainer guidance

1. Is WSLg an intended/supported environment?
2. Which official release artifact currently supports relay-mesh?
3. Was Buzz 0.5.0 Linux built without mesh-llm, and should Desktop have hidden that provider?
4. Is there a supported safe-rendering mode for WebKitGTK beyond environment variables?
5. Is the 0.5.1 AppImage expected to run on Ubuntu 24.04/WSLg?
6. Is a signed current Windows build planned?
7. Has buzz-acp.exe been submitted to Microsoft for malware-analysis review?
8. What is the expected number of claude-agent-acp processes for one agent with parallelism 1?
9. Which logs or diagnostics would be most useful for separate follow-up issues?

I am available to retest patched or signed artifacts on the same Windows + WSLg host.