ZeroClaw

ZeroClaw puts agent-authored config behind operator-computed previews

ZeroClaw proposes a config_patch tool whose approval summary is computed by the host, redacts secrets and writes only to disk until reload. Current gateway and Telegram work around authenticated ingress and per-user session ownership shows the same direction: authority should be explicit before dispatch.

← Back to homeOriginal source ↗

zeroclaw-labs/zeroclaw PR #9828 is the inspected primary source: “feat(tools): agent-facing config authoring with operator-approved policy previews.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- zeroclaw-labs/zeroclaw PR #9828 was created 2026-08-07T18:45:22Z and was open at inspection; its title is “feat(tools): agent-facing config authoring with operator-approved policy previews.” - zeroclaw-labs/zeroclaw PR #9744 was created 2026-08-04T07:33:10Z and was open at inspection; its title is “refactor(gateway): require authenticated webhook ingress before agent dispatch.” - zeroclaw-labs/zeroclaw PR #9772 was created 2026-08-05T19:07:53Z and was open at inspection; its title is “feat(telegram): add per_user_session toggle for shared group-chat sessions.” - The repository reported 32538 stars, 720 open issues, default branch master, and last push 2026-08-08T23:36:32Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw PR #9828 reports: Summary **Base branch:** master **What changed and why:** Gives agents a validated, operator-approved path to author config, replacing the raw echo > config.toml a shell-capable agent reaches for today. Six commits, each independently testable: 1. **One JSON Patch implementation.** The gateway's PATCH /api/config and the CLI's zeroclaw config patch each carried their own op loop over the same five operations; a component test existed only to assert the two produced identical error envelopes. zeroclaw_config::patch now owns the shape, parser, op loop, and prop-metadata helpers. The gateway's 183-line inline loop becomes a five-line call. Applying is deliberately separate from persisting: apply_patch_ops mutates a &mut Config in memory only, so a caller can apply a patch to a *copy* to answer "what would this do?" without committing it. 2. **The CLI uses it too**, deleting its ~290-line copy. Error envelopes are now identical to the gateway's for every input, and comment ops (which the old CLI loop parsed and silently dropped) now work. 3. **The config_patch tool.** An agent drafts ops; the existing per-tool approval gate puts

zeroclaw-labs/zeroclaw PR #9744 reports: Summary **Base branch:** master **What changed and why:** Adds crates/zeroclaw-gateway/src/webhook_ingress.rs: a typed authenticated-ingress boundary between transport-level webhook verification and agent dispatch. A sealed VerifiedWebhookIngress proof (private fields, no Clone, mintable only by a successful authenticate call) carries the verified request bytes, and the shared gateway-webhook helper dispatch_verified_webhook consumes it. "This request was verified" is now a type-level requirement of the dispatch path instead of a per-handler convention. authenticate owns the fail-closed credential policy centrally: a missing, blank, or unresolved required secret refuses with 401 before any payload byte is parsed. The provider-specific signature algorithm and header format stay in each transport handler as a closure that only runs after the credential resolves, and only over the exact bytes the proof will carry. Migrates all four message-dispatching webhook handlers (WhatsApp Cloud, Linq, WATI, Nextcloud Talk) onto the contract, replacing four duplicated parse -> autosave -> chat -> send chains with one shared gateway-webhook helper (inbound log, session key, autosave, agent dispatch, reply delivery, quickstart/error fallback, synchronous or fast-ack execution). This remains an intermediate path until gateway

zeroclaw-labs/zeroclaw PR #9772 reports: Summary **Base branch:** master **What changed and why:** Telegram group sessions are hardcoded to ChannelConversationScope::Sender, so when several people collaborate with the bot in one group or forum topic — one teammate uploads a file and states the task, another asks the follow-up — the second teammate lands in an empty session. The bot has no memory of the file or the task even though everything happened in the same visible topic. Adds channels.telegram..per_user_session (default true, current behavior preserved). When false, inbound group/supergroup messages carry ChannelConversationScope::ReplyTarget, so the chat shares one session keyed on the existing reply_target (chat_id, or chat_id:message_thread_id in forums). Forum topics therefore stay isolated from each other; only the per-sender split *inside* a topic goes away. Mirrors the knob the Lark channel already ships under the same name (channels.lark.per_user_session, added in #7256). Telegram had no equivalent. msg.sender is deliberately left untouched — it still carries the real sender, so authz, allowlists, and identity attribution keep working. This follows the WhatsApp group-scope precedent (group_context_scope) rather than Lark's sender-substitution, and should compose with

Why it matters

Letting an agent edit policy is less dangerous when the model cannot write the approval argument, chat participants cannot grant operator authority, and changes do not expand the running turn. The operator test is whether visible output, retained state and authority still describe the same event after retries, background work or restart.

Current

The primary record was open when captured on 2026-08-09. The tagged-release baseline was v0.8.4 published 2026-08-02T21:00:00Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/zeroclaw-labs/zeroclaw/pull/9828. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/pull/9744 and https://github.com/zeroclaw-labs/zeroclaw/pull/9772. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Keep config mutation synchronous, previewed and reload-bound. Test that every channel maps message identity to the same approval and session owner. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.