ZeroClaw repairs a case-sensitive command allowlist on Unix

zeroclaw-labs/zeroclaw PR #9568 is the inspected primary source: “fix(security): match command allowlist entries case-insensitively on Unix.” The two related records below were inspected as supporting context, not treated as independent confirmation.

The facts

- zeroclaw-labs/zeroclaw PR #9568 was created 2026-07-30T22:35:49Z and was open at inspection; its title is “fix(security): match command allowlist entries case-insensitively on Unix.” - zeroclaw-labs/zeroclaw issue #9566 was created 2026-07-30T21:25:35Z and was open at inspection; its title is “[Bug]: uppercase allowed_commands entries never match on Unix (regressed from #4552).” - zeroclaw-labs/zeroclaw PR #9569 was created 2026-07-30T22:35:59Z and was open at inspection; its title is “fix(gateway): fail closed when a WhatsApp Cloud or Linq webhook cannot be verified.” - The repository reported 32450 stars, 659 open issues, default branch master, and last push 2026-07-31T00:21:34Z. - The latest tagged-release baseline checked was v0.8.3 published 2026-07-16T01:47:13Z.

What changed

zeroclaw-labs/zeroclaw PR #9568 reports: Summary **Base branch:** master **What changed and why:** is_allowlist_entry_match compared the allowlist entry against the executable basename with a case-sensitive ==, while the only case folding in the function was gated to #[cfg(target_os = "windows")]. Both callers (policy.rs:1370, policy.rs:1470) lowercase the basename before passing it in, so on Unix the comparison was always "entry as written" against "basename lowercased". Net effect: an allowed_commands entry containing any uppercase, such as "Git" or "Docker", could never match anything, and the command was refused with nothing to indicate the entry itself was the

zeroclaw-labs/zeroclaw issue #9566 reports: Affected component security/sandbox Severity S2 - degraded behavior Current behavior An allowed_commands entry containing any uppercase character can never match on Unix, so the command it names is silently denied. is_allowlist_entry_match compares the allowlist entry against the executable basename with an exact, case-sensitive ==, and the only case-folding in the function is gated to Windows: Meanwhile the callers lowercase executable_base before handing it in, at policy.rs:1209, policy.rs:1370, and policy.rs:1470: So on Unix the comparison is always " " == " ". An entry such as "Git", "Docker", or "CMD" cannot

zeroclaw-labs/zeroclaw PR #9569 reports: Summary **Base branch:** master **What changed and why:** process_whatsapp_message and process_linq_webhook guarded signature verification behind if let Some(secret) = secret {... } with no else. With no secret configured, the whole verification block was skipped and execution fell through to parse_webhook_payload and agent dispatch. Anyone who knew the webhook URL could inject messages impersonating any sender, reaching tool execution, memory writes, and outbound messages under the operator's account. Both now reject with 401 before the body is parsed, matching the shape process_nextcloud_talk_webhook adopted in #9181. The secret maps already

Why it matters

An allowlist that silently denies configured commands is an availability defect, while normalization in the wrong direction can become an authorization defect. The comparison needs one canonical form and tests that preserve exact policy scope. This is an operator boundary: persisted state, execution ownership and visible controls must describe the same event. A workaround that broadens access, deletes state or hides the symptom would trade a visible defect for an unmeasured one.

Current

The primary record was open when captured on 2026-07-31. The release baseline was v0.8.3 published 2026-07-16T01:47:13Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/zeroclaw-labs/zeroclaw/pull/9568. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/issues/9566 and https://github.com/zeroclaw-labs/zeroclaw/pull/9569. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly 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. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Verify mixed-case entries and non-ASCII boundaries, keep deny behavior explicit, and confirm webhook verification failures remain closed rather than falling through to untrusted delivery. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

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.