ZeroClaw layers filesystem tiers, plugin isolation and webhook identity

zeroclaw-labs/zeroclaw PR #10100 is the inspected primary source: “feat(security): honor allowed_roots tiers in the Landlock sandbox.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- zeroclaw-labs/zeroclaw PR #10100 was created 2026-08-18T20:15:00Z and was open at inspection; its title is “feat(security): honor allowed_roots tiers in the Landlock sandbox.” - zeroclaw-labs/zeroclaw PR #10093 was created 2026-08-18T18:28:36Z and was open at inspection; its title is “fix(hardware): isolate manifest-installed plugin subprocesses.” - zeroclaw-labs/zeroclaw PR #10016 was created 2026-08-15T18:09:42Z and was open at inspection; its title is “fix(hooks): correlate webhook audit calls by identity.” - The repository reported 32625 stars, 770 open issues, default branch master, and last push 2026-08-20T22:32:52Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw PR #10100 reports: Summary **Base branch:** master (all contributions) **What changed and why:** SecurityPolicy exposes three allowed-roots tiers (allowed_roots, allowed_roots_read_only, allowed_roots_write_only), and the application layer honors them — but LandlockSandbox only ever received workspace_dir. Any path the policy permitted outside the primary workspace was still denied by the kernel. Config said allowed, kernel said no, and Landlock was silently *more* restrictive than the configured policy. Introduces SandboxExtraRoots to carry those tiers from config through detection into the backend, so the sandbox is constructed with the same set of roots the policy layer already believes are reachable. LandlockSandbox::with_roots applies each tier with the access rights that match its meaning: read-write, read-only, and write-only, rather than flattening them into a single grant. Threads the roots through create_sandbox, detect_best_sandbox, and sandbox_posture, plus the tools/mod.rs call site, so reported posture and actual enforcement cannot disagree. sandbox_posture in particular must see the same roots, or zeroclaw would report a backend as usable that then denies configured paths at runtime. Adds landlock_with_roots_grants_extra_allowed_root_access, asserting the read-write tier is readable and writable, the read-only tier is readable, and that writing to the read-only tier is denied — so the tiers are proven distinct rather than uniformly granted. **Scope boundary:** Does not change *which* roots are allowed; it only makes the kernel agree with the policy that already granted them. No new

zeroclaw-labs/zeroclaw PR #10093 reports: Summary **Base branch:** master **What changed and why:** Clear the inherited host environment before starting manifest-installed hardware plugin subprocesses, then restore only the small cross-platform environment allowlist needed to locate and run the executable. Drain stdout and stderr concurrently so a plugin that writes heavily to stderr cannot deadlock before returning its first JSON result. Apply the first-result deadline to request writes as well as the first stdout line, require the child to exit after returning a result, and attempt to kill and await it after timeout, I/O failure, or incomplete exit. Cleanup waits are bounded; if foreground reaping cannot finish, ownership moves to an attributed background reaper. Keep stderr diagnostics bounded while continuing to drain the stream, preventing error reporting from creating a second output backpressure path. **Scope boundary:** This PR changes only manifest-installed native hardware plugins loaded from ~/.zeroclaw/tools/ /. It does not change built-in Arduino, Nucleo, Pico, or UF2 deployment subprocesses, process-group or descendant termination, or the plugin protocol's unbounded first stdout line. **Blast radius:** Operators with manifest-installed hardware plugins may need to update plugins that implicitly depended on arbitrary inherited environment variables. The manifest loader, built-in hardware deployment paths, WASM plugins, configuration, and public Rust APIs are unchanged. **Linked issue(s):** None. This is a bounded source-level hardening follow-up. **Labels:** bug, hardware, domain:security, risk:high, size:L What this

zeroclaw-labs/zeroclaw PR #10016 reports: Stacked dependency: #9995 at 4cee52dee4b48eb685734b19ad3b5e3b1b049e2b; the branch will be refreshed onto master after the parent lands. Summary **Base branch:** master (all contributions) **What changed and why:** Adds an opaque per-invocation context to tool-call hooks while preserving existing hook implementations through default legacy delegation. Uses that identity to match webhook audit arguments to the exact tool invocation, including when same-tool calls finish out of order. Bounds abandoned argument snapshots to 1,024 entries and ensures an evicted or missing snapshot produces args: null instead of borrowing another call's data. This is an entry bound, not a retained-byte cap. Isolates after-hook panics so one hook cannot prevent later handlers from observing completion. **Scope boundary:** The child-owned delta does not change webhook configuration, payload fields, URL validation, redaction rules, provider tool-call IDs, or non-tool hooks. Existing handler implementations remain source-compatible, but retained legacy runner and direct handler calls cannot establish cross-phase identity and webhook audit therefore emits args: null on those calls. It does not add background cleanup or persistence. **Blast radius:** Changes the additive public hook API and runtime tool-call dispatch used by hook integrations. Existing handlers retain their legacy callbacks unchanged. **Linked issue(s):** None. **Labels:** bug, agent, config, runtime, tests, domain:security, risk:high, size:XL What this does, simply The webhook audit hook can optionally include tool arguments in an outbound audit event. Previously

Why it matters

Agent plugins combine filesystem access, subprocess execution and external callbacks. Treating those as separate checkboxes leaves gaps between the policy decision and the process that actually acts. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-21. 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/10100. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/pull/10093 and https://github.com/zeroclaw-labs/zeroclaw/pull/10016. 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

Derive sandbox roots, subprocess isolation and webhook audit identity from one capability grant, then test denial and attribution at each boundary. 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.