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

## 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:

```text
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:

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

Desktop log:

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

Other recurring messages:

```text
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:

```text
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`

```text
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:

```text
WEBKIT_DISABLE_DMABUF_RENDERER=1 — AppImage
```

It then failed with:

```text
/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:

```text
Buzz_0.4.26_x64-setup_alpha-unsigned.exe
```

### Defender result

Microsoft Defender detected:

```text
Trojan:Win32/Bearfoos.A!ml
```

Affected file:

```text
C:\Users\\AppData\Local\Buzz\buzz-acp.exe
```

After Defender quarantined/removed the file, Buzz displayed:

```text
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:

```text
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:

```text
turn_liveness
```

No final model response arrived.

At the same time:

```text
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:

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

Result:

```text
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.