Motivation
Buzz Desktop can run ZeroClaw successfully through a custom ACP runtime, but the setup currently requires users to understand implementation details from both products:
- Manually register a custom harness with command
zeroclaw and argument acp.
- Configure a persistent ZeroClaw
[acp].default_agent because a generic stdio ACP client does not send ZeroClaw's agentAlias extension.
- Put a ZeroClaw agent alias such as
fable into model-shaped UI even though the alias selects an agent, not an underlying model.
- Diagnose an invalid
session/new request only after the managed agent starts.
This makes an otherwise working integration difficult to discover and easy to misconfigure.
Proposed solution
Add ZeroClaw as a native managed-agent runtime alongside the existing runtime presets.
- Register a preset that launches
zeroclaw acp, with the ZeroClaw ACP documentation and supported installation guidance.
- Expose a runtime-specific Agent alias field instead of treating the alias as a provider or model.
- Keep provider, model, tools, and security configuration authoritative in ZeroClaw rather than duplicating those settings in Buzz.
- Pass the selected alias through a process-scoped ZeroClaw selector when available. For older ZeroClaw versions, show an actionable instruction to set the ACP default agent.
- Run an ACP readiness check that covers
initialize and session/new, then surface the selected runtime and alias in the managed-agent summary or logs.
- Hide provider/model requirements that do not apply to the ZeroClaw runtime.
The first version can accept a manually entered alias. Optional alias discovery can be added when ZeroClaw exposes a stable machine-readable listing contract.
Alternatives considered
- Keep using a custom harness JSON file. This works, but it leaves discovery, validation, and field semantics to the user.
- Create one custom runtime entry per ZeroClaw agent. This duplicates launcher configuration and still lacks readiness validation.
- Continue overloading the model field with the agent alias. This obscures which product owns model selection and makes runtime self-reporting misleading.
- Require a global ZeroClaw default agent. This prevents independent Buzz runtime entries from selecting different ZeroClaw agents cleanly.
Additional context
The custom integration has been exercised end to end with Buzz Desktop 0.5.3 and ZeroClaw ACP 0.8.3. No existing Buzz issue or pull request matching a native ZeroClaw runtime was found.
PR #3868 is the expected implementation foundation for this issue. Its first-class runtime catalogue, compatibility and authentication probes, readiness handling, and onboarding hooks should be reused rather than creating a parallel ZeroClaw-specific path. ZeroClaw should remain a separate follow-up instead of expanding #3868's OpenClaw scope.
Related but separate work:
ZeroClaw's current ACP alias-selection contract is documented here:
https://github.com/zeroclaw-labs/zeroclaw/blob/master/docs/book/src/channels/acp.md#sessionnew
Motivation
Buzz Desktop can run ZeroClaw successfully through a custom ACP runtime, but the setup currently requires users to understand implementation details from both products:
zeroclawand argumentacp.[acp].default_agentbecause a generic stdio ACP client does not send ZeroClaw'sagentAliasextension.fableinto model-shaped UI even though the alias selects an agent, not an underlying model.session/newrequest only after the managed agent starts.This makes an otherwise working integration difficult to discover and easy to misconfigure.
Proposed solution
Add ZeroClaw as a native managed-agent runtime alongside the existing runtime presets.
zeroclaw acp, with the ZeroClaw ACP documentation and supported installation guidance.initializeandsession/new, then surface the selected runtime and alias in the managed-agent summary or logs.The first version can accept a manually entered alias. Optional alias discovery can be added when ZeroClaw exposes a stable machine-readable listing contract.
Alternatives considered
Additional context
The custom integration has been exercised end to end with Buzz Desktop 0.5.3 and ZeroClaw ACP 0.8.3. No existing Buzz issue or pull request matching a native ZeroClaw runtime was found.
PR #3868 is the expected implementation foundation for this issue. Its first-class runtime catalogue, compatibility and authentication probes, readiness handling, and onboarding hooks should be reused rather than creating a parallel ZeroClaw-specific path. ZeroClaw should remain a separate follow-up instead of expanding #3868's OpenClaw scope.
Related but separate work:
ZeroClaw's current ACP alias-selection contract is documented here:
https://github.com/zeroclaw-labs/zeroclaw/blob/master/docs/book/src/channels/acp.md#sessionnew