ZeroClaw
ZeroClaw adds a channel notice before context compression
ZeroClaw’s channel work adds an opt-in plain-language notice before proactive history compression, without exposing token budgets or changing summarization. Adjacent reports cover crash loops from enabled channels with empty credentials and requests for per-execution confirmation of high-risk shell commands.
zeroclaw-labs/zeroclaw PR #7162 is the inspected primary source: “feat(channels): notify before context compression.” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- zeroclaw-labs/zeroclaw PR #7162 was created 2026-06-03T15:10:25Z and was closed at inspection; its title is “feat(channels): notify before context compression.” - zeroclaw-labs/zeroclaw issue #6724 was created 2026-05-16T18:34:44Z and was closed at inspection; its title is “[Bug]: Enabled Signal or Voice Call channel with empty credentials can crashloop the supervisor.” - zeroclaw-labs/zeroclaw issue #6996 was created 2026-05-28T23:56:00Z and was open at inspection; its title is “RFC: Granular sandbox policy — filesystem and network restrictions.” - The repository reported 32465 stars, 656 open issues, default branch master, and last push 2026-08-01T00:51:18Z. - The latest tagged-release baseline checked was v0.8.3 published 2026-07-16T01:47:13Z.
What changed
zeroclaw-labs/zeroclaw PR #7162 reports: Summary **Base branch:** master (all contributions) **What changed and why:** Adds an opt-in generic channel-visible notice when a reply-eligible channel turn is expected to condense/trim earlier conversation to stay within the context budget. Keeps the notice plain-language and avoids exposing token counts, budgets, threshold ratios, or other internal mechanics to end users. Adds notify_on_compression under context compression config so operators can enable the notice explicitly. **Scope boundary:** This does not change trim/compression behavior, summarization prompts, provider calls, memory persistence, streaming, or any channel-specific implementation. **Blast radius:** Agent replies on configured channels may include one additional progress notice only when proactive history maintenance is needed, notification
zeroclaw-labs/zeroclaw issue #6724 reports: Summary If a user adds channel blocks via the dashboard UX (Signal, Voice Call, etc.) but doesn't actually fill in credentials (so each ends up with enabled = false), the channels orchestrator boots, finds nothing actually enabled, exits, and the supervisor restarts it — every ~2 seconds, forever. The first-boot path correctly logs "No channels configured; channel supervisor disabled" and never spawns the orchestrator. After a daemon restart (or possibly some state transition I haven't pinned down), the second-boot path DOES spawn the orchestrator, which then enters the exit-restart loop. Symptom (repeating every ~2s in the daemon log) The "Warming up provider connection pool" line
zeroclaw-labs/zeroclaw issue #6996 reports: Problem ZeroClaw has two filesystem-policy layers that have historically drifted: application-layer path admission in tools and SecurityPolicy; operating-system sandbox backends such as Bubblewrap, Landlock, and Seatbelt. Agent risk profiles already express workspace and path restrictions, but OS backends largely enforce backend-local hardcoded policies. A configuration can therefore describe one boundary while a tool guard or child process enforces another. Security status must also distinguish application-layer enforcement from kernel or namespace confinement instead of presenting them as equivalent. The immediate priority is one canonical filesystem-policy model and resolver. Network confinement is a separate security decision and should not be bundled into the first filesystem slice. Proposal
Why it matters
Compression changes what a user can expect the agent to remember. A restrained notice makes that boundary visible, but it should not become a stream of internal telemetry or imply that persistence is guaranteed. 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 closed when captured on 2026-08-01. 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/7162. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/issues/6724 and https://github.com/zeroclaw-labs/zeroclaw/issues/6996. 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
Test reply-eligible and no-reply turns, rate-limit notices, fail configuration validation before supervisors start, and keep high-risk command confirmation independent of memory UX. 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.