ZeroClaw repairs cron intent and narrows shared memory grants

zeroclaw-labs/zeroclaw PR #10258 is the inspected primary source: “fix(runtime/cron): map command patches onto agent job prompts.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- zeroclaw-labs/zeroclaw PR #10258 was created 2026-08-22T11:06:02Z and was open at inspection; its title is “fix(runtime/cron): map command patches onto agent job prompts.” - zeroclaw-labs/zeroclaw PR #10253 was created 2026-08-22T08:41:04Z and was open at inspection; its title is “fix(cron): preserve scheduler workspace policy.” - zeroclaw-labs/zeroclaw PR #10252 was created 2026-08-22T08:24:51Z and was open at inspection; its title is “feat(memory): add category-scoped cross-agent grants.” - The repository reported 32639 stars, 786 open issues, default branch master, and last push 2026-08-23T20:34:55Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw PR #10258 reports: Summary **Base branch:** master (all contributions) **What changed and why:** **Bug:** zeroclaw cron update --command '…' (and cron_update patch.command) on an agent job writes the unused command column and can run shell-policy validation on the prompt text. The next agent run still reads job.prompt, so the old prompt keeps firing even though the update printed ok. **Cause:** CLI/tool patches always set CronJobPatch.command. update_shell_job_with_approval validated and persisted that field without checking JobType. PATCH /api/cron/:id already remaps with command.or(prompt) for agent jobs. **Fix:** Remap command onto prompt for agent jobs before shell-policy validation, matching the HTTP PATCH contract. Shell jobs still validate and persist command. **Review follow-up:** After that remap, cron update confirmation still printed cli-cron-cmd from the now-empty command column. Agent updates now render cli-cron-prompt from job.prompt; shell updates still render cli-cron-cmd. cron_update patch.command schema documents the same compatibility mapping. **Review follow-up:** cron update --agent help no longer implies every --command value is shell-policy gated; it now says the alias is required and that the risk profile gates shell commands for shell jobs. CronUpdateTool::execute has a regression for agent patch.command remaps. **Test:** Agent --command updates prompt and leaves command empty; confirmation prints the remapped prompt, not an empty Cmd line; shell --command still updates and confirms command; agent prompt text that looks like a blocked shell is accepted; disallowed shell patches

zeroclaw-labs/zeroclaw PR #10253 reports: Summary **Base branch:** master **What changed and why:** Stop run_agent_job from resolving a second SecurityPolicy through SubAgentSpawn::for_agent after the scheduler has already resolved the owning agent's policy. Derive the agent-run overrides from the policy passed by the scheduler, so the configured workspace boundary and shared policy state reach the agent loop unchanged. Preserve the existing cron-agent default tool exclusions and explicit allowed_tools behavior. Add a production-boundary regression that drives run_agent_job through agent::run and the real shell tool, including one retry, a repeated run, and three concurrent runs. **Scope boundary:** This PR changes only policy handoff for agent-type cron jobs. It does not change scheduler retries, claims, concurrency, shell-job execution, configuration schema, or policy semantics for CLI/gateway runs. **Blast radius:** The cron scheduler to agent-loop security-policy handoff. Shell cron jobs and non-cron agent paths are unchanged. **Linked issue(s):** Related #9206 **Labels:** cron, runtime Testing How you can test **Reviewer testing requested?** Yes — the issue reports a daemon-only intermittent boundary symptom that is not reproducible in this local test environment. **Interface(s) exercised:** cli cron management with a daemon-scheduled agent run. **Setup / preconditions:** Run the daemon from a working directory that is not the configured absolute workspace for an agent alias. Configure an agent-type cron job with an isolated session and a prompt that asks the model to invoke the shell

zeroclaw-labs/zeroclaw PR #10252 reports: Summary **Base branch:** master **What changed and why:** Add typed cross-agent memory grants with optional exact category scopes while preserving legacy string entries as unrestricted grants. Enforce category scope across every sibling-visible read path, including recall, point reads, listing, export, and counts. Reject scoped grants for Markdown memory at validation and fail again in the factory so a validation warning cannot weaken the boundary at boot. Preserve alias rename/delete cascades, duplicate-grant validation, non-transitive sharing, and operator documentation. Refill category-scoped recall candidates after backend truncation so denied rows cannot cause permitted rows to be silently under-returned. **Scope boundary:** This changes only explicit cross-agent memory sharing. It does not change backend query semantics, default access, bare-grant behavior, or transitive sharing. **Blast radius:** Configuration parsing and validation, the agent-scoped memory wrapper and factory wiring, runtime delegation dispatch, and multi-agent documentation. **Linked issue(s):** Fixes #8983 **Labels:** docs, config, memory, runtime Testing How you can test **Reviewer testing requested?** N/A — deterministic unit and factory tests cover the security boundary and the category-filter refill behavior across the affected read paths; a manual interface path would not add equivalent coverage. How I tested cargo fmt --all -- --check cargo test --locked -p zeroclaw-memory — 509 unit tests passed, 4 integration tests passed, and doc-tests passed. cargo clippy --locked -p zeroclaw-memory --all-targets -- -D warnings git diff

Why it matters

Scheduled intent, filesystem policy and memory visibility are one authority chain; a green update receipt is worthless if the next run reads another field or another workspace. 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-24. 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/10258. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/pull/10253 and https://github.com/zeroclaw-labs/zeroclaw/pull/10252. 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

Render the field the scheduler consumes, pass one resolved policy into the loop, and enforce category scopes on every sibling-visible read path. 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.