Run against the real clawmates repo with a task that cannot be faked
from filenames: trace every hop of a mission agent's tool call from the
guest hook to the recorded event, naming file, function, and guest vs
host for each.
It produced a 189-line research/GATE-MAP.md describing code committed
the SAME DAY — the four-field NODE_EXTRACT including agent_type, the
shadow-mode would-deny.jsonl semantics, install_with — and all six of
its line citations verify exactly. Nothing hallucinated. That is a
stronger result than the judge's verdict, which could only check that
the structure was present.
Also recorded: agents reach for Bash. 74 Bash calls against 34 Read, 3
Glob, 1 Edit, 1 Agent — a mapping mission that could have used Grep used
Bash 33 times. So the allowlist's dedicated-tool entries may never be
exercised, and the surface that actually needs governing is Bash, which
the floor rules already cover.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
First run of the backend template, 2026-09-22. All five roles
provisioned with real agents; the mission delivered cursor pagination
(Paged<T>, paginate<T: Clone>, module declared, cargo test 3/0) and was
judged met on the FIRST pass, 2 files pushed.
One run is not maturity, but it answers the question the review could
not: whether anything staffed from this template runs at all. It does.
It also gave the task-permission shadow its first confirmed Edit call —
Bash 8, Read 2, Write 2, Edit 1, zero would-deny.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
CLAWMATES_PUBLIC_URL was unset, so the podcast feed built every episode
URL from the localhost default: valid XML that no podcast app could
play. Set in the repo override and on prod (https://clawmates.work);
the feed now carries real enclosure URLs for both episodes.
Addendum 7 records the four defects found working on this recipe — only
one of which the plan predicted — and the evidence for each.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
A review of what our agents can actually be asked to do, graded by
evidence rather than by what the TOML declares.
Recipes: research_and_code (13 harness scenarios) and research_only
(staffing measured and corrected — 1 of 9 applicable skills under the old
rust_sdlc default, 4 of 4 under topic_research) are proven.
security_hardening, benchmark and refactor are exercised once each.
continuous_research is the outlier: the most moving parts of any recipe,
ran twice today, and NOTHING in the harness would notice if it broke.
Dead keys the recipes lean on, from phase_config::DECLARED_BUT_UNREAD:
loop, produces, input_from_phase, and mcp_bundles at phase level. Not
hidden — security_hardening.toml annotates its own decoration inline, and
the other five should copy that. The risk is a reader taking
loop = "until_no_more_int_items" for a loop.
Teams: all 12 resolve every declared skill (0 unbound, the
skill-binding-repair work holding), but only rust_sdlc, topic_research
and continuous_research have a run behind them. The other nine are
well-formed scaffolding. Five are blocked on a target stack we do not
have a repo for; four could be exercised against repositories we already
have, and nobody currently knows whether they run at all.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
Four measurements decide the shape, all taken today:
1. --allowedTools is not an enforcement boundary. ListAgents and
ScheduleWakeup ran on microvm missions whose list is Read Edit Write
Bash Agent. The flag governs prompting, not availability, so any
task-permission layer must be enforced by our own gate.
2. The guest already has every tool's output on disk (the tap appends the
whole payload, tool_response included), so taint is computable
guest-locally with no network call and no added latency.
3. The taint store would already be protected — the hook-files rule
refuses reads and writes to /root/toolhooks from both Bash and the
write tools.
4. Provenance is a CONTAINER-tier control. A microVM reaches only the
provider and the forge through a name-matched CONNECT allow-list; a
container reaches any public host. Saying it matters equally on both
would be padding.
Task permission: a per-phase "agent_tools" key (NOT "tools", which
security_scan already owns), defaulted from what phase kinds actually
used, enforced by the gate. Provenance: taint hostnames out of fetched
responses, deny an outbound call WITH A BODY whose target is one of them
— the asymmetry being that reading a host a page mentioned is research
and sending data to it is the attack. String taint is rejected outright
as a false-positive generator, which is this module's cardinal sin.
Both ship in shadow (gate.would_deny) first, because today's corpus is
171 tool calls and 15 curl invocations and cannot validate a rule.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
The role policy was unit-tested against the script the code generates.
This probes the script the SERVER INSTALLED, inside a live mission
container: the verifier's Write exits 2 with its reason, the lead's
identical Write exits 0, the verifier's Read and another role's Edit exit
0, and the denial the deployed gate wrote names role-verifier-readonly and
agent_type verifier. 5/5 on prod.
Three of the four probes are negative controls. A gate that refused
everything would pass the first and be worthless — the same trade the
module's header refuses. 'Compiled in and CI-green' and 'enforced by the
artifact in production' are different claims; the gap between them is
this module's history.
The record is matched with a shell glob on the raw JSON line, not a
nested python -c: the first version could not survive quoting through
bash, ssh and sh, and reported an empty record while the gate had written
a correct one.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
01a0c940: 7 observable skills, oracle says 5 apply, agent read 4 of those
and 0 unexpected. The one disagreement is the agent's miss —
executive-summary-writing at 0.77, unread, on a mission whose output is
digest entries.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
01a0c940 (old question): relevance 2.93-3.00, spread 0.07. 01a0c950
(kind+evidence): spread 2.98, a survey at 0.0 and a measured method paper
at 2.98, 8 of 9 tagged. The research agent reading the old manifest had
already called the score overscored, unprompted.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
Three fail-open paths on the §15 door: no env at all meant allow-all; a
governor that could not be reached approved with a WARNING; and a reply
that never said DENY — empty, truncated, a refusal — approved, because the
rule was !contains("DENY"). On the two days the judge plan emptied every
outbound action was approved by nobody.
Now: governor_allows() needs an explicit ALLOW and no DENY; both judge()
implementations return false when unreachable; with no governor the door
opens only on CLAWMATES_DOOR_POLICY=allow. Open Agent Passport (arXiv
2603.20953): 74.6% social-engineering success under a permissive policy,
0 of 879 under a restrictive one. Local override gains the governor prod
already runs.
skill_self_authoring: default flipped to OFF. No agent-authored skill has
ever been delivered to a mission or scored; prod held zero proposals.
Enable with CLAWMATES_SKILL_SELF_AUTHORING=1 once promoted skills go
through the files arm and get a Skill-Use score.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
MISSION-EGRESS.md said the fix was deliberately not applied and prescribed
DOCKER-USER. Both would now mislead. Appended what happened on 2026-09-18:
missions shared the server's subnet, DOCKER-USER loses to ts-forward on every
tailscaled restart, raw PREROUTING dropped the server's replies — and the
design that holds, verified from inside a real mission container.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
Measured on prod: 7 of 9 verdicts ran to the 12-check cap. Every round
resends the whole history, and each check's output is bounded at 12 KB — so
by the last round the judge was paying for ~144 KB of outputs it had already
read, on top of up to 120 KB of evidence, and it paid that on every round.
That is the quadratic term in a verdict's cost, and the reason a single
blocked phase could empty a weekly plan.
Before this round's results go in, every earlier tool result compacts to an
800-byte head plus a marker saying the rest was shown when the check ran.
The round that just ran stays whole; a result already carrying the marker is
left alone. The budget of checks is unchanged — each one is cheaper to
remember, not fewer to run.
Also: docs/NEXT-SESSION.md rewritten for the state as of today.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
The z.ai quota reset on schedule. glm-5.3 answers on the same key and has
since passed a real done_when — phase completed on iteration 0, with the
verdict naming the arXiv ids it checked rather than waving the phase through.
Mission 01a07498 was the failed validation run plus one change, and it closed
the honest negative the last handoff recorded: 87 tool calls, 43 from the main
turn and 44 across 4 general-purpose subagents, 4 distinct subagent_ids against
4 Agent spawns. Before this the field was correct in unit tests and had never
been watched writing.
The one change was the finding. The earlier task invited delegation and got
none; naming the tool and forbidding the single-turn shortcut produced four
spawns from the same recipe and the same delivery arm. A fan-out path that is
merely invited measures nothing.
Also records that postgres is clawmates-postgres-1 locally and
clawmates_postgres_1 on gw-04 — the wrong one reports "No such container",
which reads like a down stack rather than a typo.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
Seven commits this pass, all deployed. The handoff leads with the thing that
will otherwise waste the next session's first hour: `glm-5.3` hit a hard z.ai
quota on 2026-08-29 (code 1310, resets 09-04), it is the DEFAULT validator on
both stacks, and the `ZAI_API_KEY` fingerprints are identical — so every mission
declaring a `done_when` fails its evaluation on local and production alike,
with its artifacts fully delivered and correct.
That failure is not a bug to fix. `evaluator.rs:480` refuses to fall back to the
agent's own provider because a same-family verdict would claim an independence
it does not have. It is also NOT the malformed-prompt 429 we hit before: this
one carries a code and a reset date.
Records the validation run honestly rather than as a clean sweep. Three of four
things confirmed live — `always_inject` delivering a body beside an index entry
in one prompt, retrieval still firing through the door, the corrected gate
installed and quiet against 23 body-free Bash calls, attribution 34/34. The
fourth did not happen: those agents never delegated, so the subagent field is
written and null, and the path that motivated it has still never been watched
populating `mission_events`. A task that invites delegation does not force it;
the next attempt should instruct it outright.
Also carried forward: local test state that production does not share
(`workspace-repo-commit-protocol.always_inject = true`, set by hand), the three
fork items sitting behind one runtime image rebuild with tank offline, and two
silent-discard defects found by sweep and left unfixed — `container_tool_hooks::
install`'s outcome is recorded nowhere, which makes "did this mission run gated?"
unanswerable once the container is reaped.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
331 behind, 54 ahead. The previous scan said 218 and its conclusion about the
egress commit was wrong, so it is marked superseded rather than edited.
Merge cost is smaller than the number suggests: 660 files changed upstream, 52
by us, and **18 overlap**. `claude_cli.rs` — the provider every mission runs
through — exists in our tree and in zero upstream files, so it cannot conflict.
The find worth recording is not a feature. Upstream defaulted skills to compact
injection on 2026-08-05 (#8313), then restored the full default for v0.8.x on
2026-08-13 (#9913). Eight days. That is our `index` arm, tried at larger scale
and pulled back out of the stable line — evidence bearing directly on our own
open question of whether to flip the default, and with our own data at n=1 per
arm it argues for more pairs before flipping, not fewer.
Their documentation also states plainly what ours should: "Compact mode reduces
prompt size; it is not an isolation boundary for untrusted skill sources."
Progressive disclosure is a token optimisation. It is not a security control.
Also noted, as a documented limit rather than a surprise: upstream fixed
case-insensitive allowlist matching (#9568) and symlink-escape path resolution
(#9384) in their command gate. Ours resolves no paths, so a symlink to `curl`
defeats it.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
Plan item 4 said to pull upstream's `0db7d999a` egress policy as "defence for
the egress problem we have not solved". It cannot see the problem.
`claude_cli` runs the claude binary as a SUBPROCESS
(`Command::new(&self.binary_path).spawn()`), so every mission tool call happens
inside that child. `net_guard`'s only call sites upstream are `link_enricher`,
`helpers/domain_guard` and `plugins/egress` — ZeroClaw's own Rust HTTP. A
mission agent's `curl` never touches the guarded stack. Pulling the commit
hardens the CHAT tier; it leaves mission egress exactly as it is. Item 4 is
corrected in place rather than deleted, because the reasoning is the useful
part.
What is actually true, measured on gw-04 with controls in both directions:
positive 1.1.1.1:443 REACHABLE
negative 192.0.2.1:80 TEST-NET blocked
tailnet gw-02 100.84.218.70:22 REACHABLE
host SSH docker gw 172.23.0.1:22 REACHABLE
169.254.169.254 REACHABLE
postgres REACHABLE, password-required
LAN 192.168.1.1 blocked
A mission agent reaches the entire tailnet and SSH on its own host. It matters
more here than it would elsewhere: these agents run model-generated shell over
content fetched from the open web — 151 of 158 production Bash calls were
curl/wget — so the instruction stream and the data stream are one stream.
The first run of this probe attached only `clawmates_core`, reported "no
internet", and was discarded: its positive control failed, so it measured
nothing. A mission container is on BOTH networks and that is what must be
reproduced.
Recorded in full, including the half that is fine — postgres refuses
unauthenticated TCP and no database credentials are forwarded into a mission
container — because a report that lists only the bad half is not a measurement.
Remediation is written down and deliberately NOT applied, on the operator's
call. It is DOCKER-USER rules dropping the private world with the core subnet
accepted first; never a public host allow-list as the opening move, because
`JEPA Research` alone fetched a dozen hosts nobody would have pre-approved and
a mission that cannot read cannot do research.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz
`ClawHDF5` and `JEPA Research` were launched from the UI. The first completed,
and everything shipped over the previous two passes engaged correctly on its
first execution anywhere outside the local stack:
skills door installed — api_origin() derived the host from the server's
own container id, which had never run where it was not tested
staffing Topic Research, 3 roles / 4 deliveries, not rust_sdlc's 5 / 14
drain 92 tool calls
attribution 92 of 92, across a phase with TWO passes and six turns — the
case attribute_sessions had never met, and it attributes
nothing at all unless the counts match exactly
boundary all 8 Write/Edit paths under /mission/repo
arm inline, 0 retrievals; prod leaves the env unset
judge pass 0 met=false "zero URLs — grep -c http returns 0"
pass 1 met=true "57 http references"
The judge line is the one worth rereading: the loop converged on the exact
mechanically-checked defect it named, and pass 0 would otherwise have shipped
a report whose every claim was unattributed while reporting `completed`.
Two traps recorded rather than smoothed over:
- The drain selects phases `IN ('completed','failed')`, so a phase on its
second pass shows zero tool calls and reads as broken while being correct.
- I reused a diagnostic query with no `WHERE mission_id`. That was fine while
prod held one mission and silently wrong the moment a second launched — it
compared one mission's tap against two missions' events. The production
drain query is correctly scoped; the diagnostic was not.
Unexplained: one agent called the `Agent` tool 4 times. Mission agents are
spawning subagents and nothing in our design accounts for it.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Runs 9 and 10: identical task text, one server process, and a task that never
mentions skills, MCP or retrieval. Run 8 demonstrated the instrument, but its
retrieval was instructed by the task — it showed the pipe worked, not that an
agent would judge relevance.
Under `index`, two of four skills were fetched, and attribution is the part
that matters:
Solveig (lead_researcher) -> web-search-triage
Olamide (report_writer) -> scientific-writing-conventions
Each agent reached for the skill bound to its OWN role and neither reached for
another's. An agent that fetched all four would have shown only that it could.
The regression the A/B existed to catch did not appear: 34% fewer tokens, 59
tool calls against 89, both arms passed the independent judge, and the
deliverables came out slightly larger rather than thinner.
Two readings the data does not support, recorded because the first draft of
this section made one of them:
- Every `tool.call` in a phase carries the DRAIN timestamp, not the call time.
All 59 rows of run 10 read `12:48:12`. Ordering by that column said the
report writer had fetched both skills; `agent_id` says otherwise.
- The prompt saving is 15-43%, not an order of magnitude. Skill bodies are a
minority of a turn prompt. Progressive disclosure is worth doing for Trigger,
not for context economy.
`workspace-repo-commit-protocol` scores Trigger=FAIL beside boundary=pass: it
behaved correctly without reading the rule. That verdict is left standing and
argued with in the text rather than tuned away.
n=1 per arm. A signal, not a rate.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Trigger — did the agent reach for the skill when it applied? — cannot be
measured while every body is inlined into the prompt. Nothing was reached
for. `skill_use` has been reporting `NotObservable` for that reason, and it
was right to.
The skills door made retrieval possible; this makes it a delivery arm.
`index` sends each pinned skill's name, description, `when_to_use` and the
uri that returns its body, and the agent fetches what it judges relevant.
`inline` is unchanged and stays the default.
An A/B rather than a switch, because `index` can only cost Compliance: under
`inline` the procedure sits in front of the model whether or not it noticed
it applied. Trading a measured axis for an unmeasured regression in another
is not an improvement, so both arms stay runnable and the arm is recorded on
the mission row.
Three things the mechanism refuses to do:
- `index` without a door falls back to `inline`. An index names bodies and
says how to fetch them; with no `clawmates_skills` server reachable that is
a list of dead ends, and it fails as an agent ignoring its skills rather
than as a missing config. `install_skills_door` now returns whether it
installed, because the caller needs the answer and not just the log line.
- The scorer reads the arm off the recorded PROMPT, not off the mission row.
The row says what the mission is configured to do now; the score is being
computed against a turn that ran then.
- Under `index`, a skill that was offered and never read is a Fail, not the
inline arm's `NotObservable` — but only where the skill had a checkable
consequence in that phase. Reusing the inline text would have said "this
skill was inlined into the prompt" about a skill whose body was never sent,
and scoring a real miss as a structural blind spot is the failure this
measurement already made once.
The arm is per mission (`config.skill_delivery`), not only per deployment.
Both arms run against one server process; restarting between them would put a
confound in the comparison that the numbers would not show.
829 tests, 108 binaries, green.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
22 commits pushed, CI green, deployed. Items 1-3 of the previous list are
done: staffing, attribution, and the door. Trigger is measured and
red-first turned out observable from run outputs rather than from the
diff — the previous list was wrong about that, and the skill says why.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
Run 8, all three agents, per-agent attributed:
Pedro / Ebele / Ahmad — ListMcpResourcesTool, ReadMcpResourceTool
The agent's own report: 53 resources from `clawmates_skills`, and
`skill:global/workspace-repo-commit-protocol` read back as
`# Mission repo + commit protocol`. So the wiring works end to end, not
just the mechanism.
And a correction to the commit before this one. It recorded "58 MCP
resources" as a measurement. That number was the model's paraphrase in a
probe transcript, not an observation. `resources/list` returns 53 and
`select count(*) from skills` is 53.
Noted in the doc rather than quietly changed, because it is the same
error this project keeps making — a model's self-report treated as
evidence — and I made it in the very document arguing for measuring
things.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
Proven against the real binary in the runtime container — connect, list
(58 resources) and read (`# Mission repo + commit protocol`, the correct
first heading). That probe is a two-minute loop; I reached for the
ten-minute rebuild-and-run-a-mission one first, and it would have found
the container-name bug sooner.
No `--allowedTools` change was needed. Recorded because the guess would
have been wrong in an expensive way: with no config read on the daemon,
"adding" the MCP tools meant overwriting the seed's `tools` list and
stripping Write and Bash from every mission agent — to solve a problem
that does not exist.
The §3 claim that this was "config, not code" is corrected in place: it
needed a credential narrow enough to leave in a container an untrusted
agent reads, and the measured proof that the credential IS narrow (same
token: 58 skills from /mcp/skills, 401 from /api/missions).
And what it does not buy, stated plainly: Trigger is still unmeasured,
because delivery still inlines. The door makes retrieval possible; making
Trigger real means switching to progressive disclosure, which could
regress Compliance and so wants an A/B rather than a flip.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
Run 5 is run 3's task against the new staffing: 5 roles → 3, 14 skill
deliveries → 4, 50KB of prompt → 24KB, and 1 of 9 delivered skills
applicable → 4 of 4. The agents produced exactly the structure the new
team's task specifies — questions.md, evidence.md, REPORT.md — with zero
writes outside /mission/repo.
The baseline says plainly that the SCORES barely moved, because they did:
run 5 is one `pass` and three `not_applicable`. What changed is what
`not_applicable` means — "no machine-checkable consequence" rather than
"this skill had nothing to do with this phase". Halving the prompt is real
but incidental. The finding is that the denominator was wrong: seven of
run 3's nine skills were never applicable, so any ratio over them measured
staffing, not skill use.
Handoff item 1 is closed and the orphan-container section now records what
was actually in it.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
Run 4 (`research_and_code`, real repo) is the first mission that could
have violated the TDD and commit checks. It exercised both, and found a
bug in one.
Claude Code writes a multi-line commit message as a heredoc inside a
command substitution:
git commit -m "$(cat <<'EOF'
INT-01 Add slugify function to src/lib.rs
…
EOF
)"
`commit_subjects` read the first line of the `-m` value, which is the
heredoc OPENER. Every commit check was scoring `$(cat <<'EOF'` — a string
the agent never wrote. It reported no violation only because that string
is not one of the never-merge messages, which is luck rather than a check.
Regression test built from the exact command in `mission_events`.
The TDD verdict came back `not_observable`, which is the honest answer and
also a real limit worth stating: the agents edited `src/lib.rs` once —
implementation and `#[cfg(test)] mod tests` in the same write — then ran
`cargo test` five times. In Rust the unit test lives in the file under
test, so that ordering is exactly what following the skill precisely looks
like from outside. The check detects "wrote source, never ran a test" and
cannot confirm red-first. Confirming it needs the diff, not the tool order.
Every one of run 4's 33 tool calls stayed inside /mission/repo.
Handoff and baseline updated: production has never run a mission (both
tables empty), a mission container has leaked since 2026-08-12 that no
reaper can see, and `research_only` staffs a five-role Rust SDLC crew on a
repo-less markdown mission — which is what "most skills score
not_applicable" has been measuring all along.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
The first live scoring of run 3 reported `cargo-test-driven-development`
and `tdd-red-green-refactor` as compliance=FAIL: files were written and no
test ever ran.
Wrong, and wrong in the way this module exists to prevent. The phase wrote
fifteen markdown notes and a helper script; there was no code to
test-drive. Reporting it as an agent failure is a system defect wearing an
agent's name — and it would have buried the actual finding, which is that
a repo-less `research_only` mission is staffed with a Rust SDLC crew whose
coder, tester, reviewer and committer have nothing to do.
The check is now scoped to files with a source extension in the languages
the skill itself names. Shell is deliberately excluded: a helper script
written during a research turn is not behaviour-adding code, and the false
failure costs more than the missed one.
Recorded in SKILL-USE-BASELINE.md as finding 8 rather than quietly
corrected. A measurement that hides its own false positives cannot be
trusted about anyone else's.
Also in the doc: the Trigger reason is half false now (the transport can
surface a tool call; we simply still inline), and the architecture doc's
observe/gate table said the container tier was ungated and unobserved,
which shipped work has made wrong.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9
TOOL-CALL-ARCHITECTURE.md said "switch claude_cli to stream-json" as the
cheapest fix. That was wrong and is now marked so, with what actually
happened: zero tool.call events with the parser working perfectly, because
TurnEvent::ToolCall only fires for tools ZeroClaw itself executes. Hooks
sidestep that entirely, and the doc now leads with the resolution rather
than the theory. A fresh session is pointed at this file, so leaving the
wrong recommendation on top would have sent it down the same path.
NEXT-SESSION.md: state header, and the ordered list rewritten — items 1-3
are done or superseded. "Give the direct-session tier a tap" is dropped with
its reason: that tier is dormant (CLAWMATES_MISSION_EXECUTOR unset), and
checking before building saved the work. New top item is watching the first
production mission, since the gate and tap are proven locally and unproven
in prod.
Added an operational section for the things that cost the most time: the
403 actions-log API, gw-04's legacy docker-compose, the socket proxy, disk
contention between manual builds and CI, and Clerk-only prod auth.
Also flagged that SKILL-USE-BASELINE.md's Trigger column is now stale in a
good way — tool calls are observable on the container tier, so Trigger can
be scored from behaviour instead of prose. That is the highest-value
follow-up.
Co-Authored-By: Claude Opus 5 <[email protected]>
Records the verified result (10 tool.call, 4 file.touch on a real mission),
how hooks succeed where stream-json could not, the production state and its
rollback, and the three same-shaped bugs the live test found.
Also records that CI's build failures were disk pressure from my own manual
runtime builds on gw-04 — not code — and that a docs-only commit was the
first casualty, which made it look like a regression.
Co-Authored-By: Claude Opus 5 <[email protected]>
Ran it against the real claude binary with the real settings document and
the real hook script. Both halves.
It blocks: asked to `curl -X POST`, the agent attempted the Bash call, the
hook fired FROM --settings, the call was refused, and denied.jsonl recorded
the payload with hook_event_name PreToolUse and the exact command. The agent
relayed the reason accurately — the text from vm_tool_gate::RULES reached
the model, which is the point of writing reasons rather than bare refusals.
It allows: `echo` and a harmless `rm -rf ./scratch-nonexistent` both ran and
denied.jsonl stayed empty. A gate that blocked everything would have passed
the first test; this is the half that rules that out — and two of this
gate's four bugs produced exactly that failure.
So the last unproven link in the chain is closed, and the gate is real in
production rather than plausibly real.
One finding worth keeping: asked to `git push --force`, the model refused on
its OWN before ever calling Bash, so the hook never fired and the test was
inconclusive. A gate test must use a command the model will actually attempt.
The model's judgement is not the gate, and testing against something it
already refuses measures nothing.
Co-Authored-By: Claude Opus 5 <[email protected]>
Tried to close the last open question — does the PreToolUse gate actually
fire in a guest — and got most of the way.
Established:
- the generated script blocks and allows correctly under DASH, not just
macOS sh: force-push and `cd /tmp && rm -rf /` return 2, while
`grep -rn 'rm -rf /' docs/` and ordinary work return 0
- without node it allows and writes the `inert` marker, so a gate that
cannot parse is distinguishable from one that matched nothing
- `claude` in the runtime image supports `--settings` (SETTINGS-OK)
- PreToolUse DOES fire under `claude -p` in this image — measured by an
earlier session and recorded in vm_stop_gate.rs:36
Unproven, and now precisely scoped: whether Claude Code honours a
PreToolUse hook supplied via `--settings <path>` specifically, with a real
agent turn. The live attempt hit the weekly subscription rate limit, and
`claude doctor` does not report hooks, so there is no non-LLM confirmation
available.
`emit_guest_assets` (ignored by default) writes the real hook script and the
real settings document to /tmp so the check can be run against the actual
binary in one docker command — no microVM, no fleet. The exact command is in
docs/NEXT-SESSION.md.
Worth stating plainly: if that link is broken, the gate is inert in
production and looks exactly like a gate that found nothing — which is the
failure mode this whole session has been about.
Full workspace suite green: 107 binaries.
Co-Authored-By: Claude Opus 5 <[email protected]>
The corrected runtime image exists on gw-04 and stays there. It delivers no
observability until TurnEvent::ToolCall can be emitted for observed calls, so
deploying it alone would be a provider output-format change carrying risk for
no benefit. Production stays on the known-good :v084.
The harmful v1 image was deleted from both hosts so it cannot be redeployed
by accident.
Co-Authored-By: Claude Opus 5 <[email protected]>
Deployed the amd64 build to gw-04 and drove a real mission. The agent used
Bash and the standard tools; no tool.call events appeared, and the gateway's
unmatched-frame histogram still showed only session_start.
The reason is structural: TurnEvent::ToolCall is emitted from
tool_execution.rs, only for tools ZeroClaw itself runs. Claude Code runs its
tools in its own subprocess, so the event never fires. A provider that knows
about the calls changes nothing by itself.
The first version was also harmful — it returned the observed calls as
tool_calls, so the loop tried to execute Claude Code's tool names and fed
"Unknown tool: Bash" back to the model. Fixed in the fork; both runtimes
rolled back to the known-good image in the meantime.
Co-Authored-By: Claude Opus 5 <[email protected]>
Run 498 passed and deployed. Confirmed on gw-04: 53 skills, 11 templates,
zero unresolved bindings, self-authoring announced ENABLED, the new
gateway_preflight answering, and migration 0080 applied.
Also records that run 497 was cancelled by the concurrency guard rather
than failing, and that the stream-json runtime image is still NOT shipped by
this pipeline.
Co-Authored-By: Claude Opus 5 <[email protected]>
Records both real causes (run 490 stomped by an overlapping run; 491-496
killed by an apostrophe closing a single-quoted sh -c block), the guard that
now catches the second class locally, and what to check when the in-flight
run settles — including that a successful build is the FIRST time these
commits reach production.
Co-Authored-By: Claude Opus 5 <[email protected]>
Establishes what is verified (the code passes on the runner host, with
cargo's real exit code), what is narrowed (493/494 die inside the Rust step
before cargo starts; 495 died before step 1), the three theories that were
wrong, and the cheapest next experiment.
Also records the two things that made this expensive: the actions-log API
returns 403 for our token, and my first reproduction piped cargo into `tail`
and reported tail's exit code.
Co-Authored-By: Claude Opus 5 <[email protected]>
Runs 490 and 491 both failed `test`. Neither failure was in the code.
Runs 490 and 491 started 16 minutes apart and a full suite takes longer
than that, so they overlapped. The first thing a run does is
`docker rm -fv cm-ci-pg` — a name every run shared — so the newer run
deleted the older run's database mid-suite. Both failed, and the failures
read as test failures.
Verified before changing anything: the exact CI command, on gw-04, against
the same warm cargo volumes and a Postgres started exactly as CI starts it,
passes on 128b423 — as do `npm ci`, `typecheck` and `vitest` on that host.
The code was never the problem.
- `concurrency: deploy-${{ gitea.ref }}` with cancel-in-progress, so runs
on a ref serialize. A superseded run tests a commit that is no longer
the tip; finishing it costs 20 minutes to learn something that no longer
matters.
- the test Postgres is named per run, so overlap cannot corrupt a run even
if the concurrency guard is later removed. Impossible rather than
unlikely.
- `--shm-size=1g` on it. Docker defaults /dev/shm to 64MB and cm-testkit
creates a database per test; Postgres exhausts its parallel-query
segments mid-run and reports `could not resize shared memory segment`
DURING MIGRATIONS, which reads like a schema fault. Hit locally on
2026-08-19; scripts/test-server.sh already carries the same flag.
The lesson is the session's own: I twice inferred a cause from a red build
without reading the failure — first node, then dash — and both were wrong.
The answer came from running the job on the runner's own host.
Co-Authored-By: Claude Opus 5 <[email protected]>
Records the state of the tree, the one step not taken (the stream-json
runtime image is built and never deployed, so no mission has confirmed
tool.call rows end to end), the ordered next steps, the decisions that are
the operator's, and what was deliberately left undone with reasons.
Also records the two corrections made this session — "missions can't call
tools" was wrong, and raw test counts are a bad coverage metric — because
both were confidently stated here before being checked.
Co-Authored-By: Claude Opus 5 <[email protected]>
Deep research into "missions can't call tools at all", which I wrote and
which is false. docs/TOOL-CALL-ARCHITECTURE.md has the full findings.
WHAT IS ACTUALLY TRUE
Three of the four mission paths end in `claude -p` with Claude Code's own
toolset and permissions PRE-ACCEPTED:
solo microVM Read Edit Write Bash Agent --permission-mode acceptEdits
composed microVM same, per node same
direct session Read Edit Write Bash acceptEdits
So the position is not "no tools". It is: mission agents run Bash and Write
with permissions pre-accepted, and nothing in this platform can gate them.
That is a stronger finding than the one it replaces — "can't call tools"
sounds like a missing feature; "calls tools freely, ungated, and mostly
unobserved" is a security posture, and it is ours.
Observe and gate are different and both are partial. vm_tool_tap is a
PostToolUse hook: it fires AFTER the tool ran and exit-0s unconditionally,
so it is telemetry and structurally cannot gate. The direct-session tier has
no tap at all. GatePolicy has exactly one enforcement site — the chat loop —
and its approvals key on (session_id, message_id), which no mission phase
can produce.
WHY THE CONTAINER TIER LOOKED TOOL-FREE
`claude_cli` runs `claude -p --output-format json`, which returns a single
final result object, and the provider hardcodes `tool_calls: Vec::new()`.
The calls happen; the transport discards them. The comment reading that
emptiness as "§15 by construction: agents are provisioned tool-free" was
inferring a design property from a serialization choice.
Verified against the deployed Claude Code 2.1.228 rather than assumed:
`--output-format stream-json --verbose` emits `tool_use` blocks with the
tool name and `tool_result` blocks. The calls are fully observable; we ask
for the wrong format.
THE DOOR WE ALREADY BUILT AND NEVER PLUGGED IN
claude_cli.rs is OURS — upstream zeroclaw-labs/zeroclaw has no such file —
and so is 88eef99d4 "claude_cli --mcp-config + allow/disallow tools (act via
door)". The provider already accepts mcp_config (claude's own MCP client
reaches our door), tools, and disallowed_tools (lock out the natives so the
gated door is the ONLY actuator). agent.config.example.toml documents the
whole shape.
In the live runtime: clawmates-mcp.json does not exist, there is no
[providers.*] block, and every mission claw binds to claude_cli.default
which sets none of it. My earlier "claude_cli cannot reach MCP, therefore
the skills server is unreachable" was wrong in its reasoning — the
capability is built, documented by us, and never deployed.
Related: we set `agents.<alias>.mcp_bundles`, which configures ZeroClaw's
OWN MCP client for its native loop. A claude_cli agent's actuator is the
claude subprocess, which reads `mcp_config` on the PROVIDER. We were turning
a knob wired to a loop that does not run.
UPSTREAM
218 commits behind. No upstream work on claude_cli (the file is ours). ACP
already exists in the fork; the three new commits are workspace-default and
localization fixes, not new capability. The one item worth pulling is
"feat(plugins): add shared egress policy foundation (#9137)" — a network
guard with DNS pinning and metadata-address blocking, defence for the egress
problem we have not solved.
Stale claims corrected in place, in topology_exec.rs and the runtime config,
so the codebase stops asserting the thing that is false.
Recommended order, cheapest first: stream-json for observability; the
PreToolUse hook for a real gate (it FIRES under claude -p per vm_stop_gate,
and has zero call sites); then deploy the door. The executor swap is NOT
recommended — the blockers are structural, not wiring, and the cheap fixes
deliver what it was wanted for.
Co-Authored-By: Claude Opus 5 <[email protected]>
Extending the Skill-Use mechanical checks, per the baseline's own next step,
found something bigger than a missing check.
THE DEFECT
`workspace-repo-commit-protocol` told agents that `/workspace/repo` was "the
ONLY path where source-modifying edits belong". The platform mounts and
advertises `/mission/repo` — 26 references in the code; `/workspace/repo`
appears in none of them.
The skill is bound on 29 role bindings and was delivered TWICE in the run
already measured, so an agent received the real path in its tool preamble
and a skill contradicting it a few hundred tokens later, in one prompt. An
agent that obeyed the skill wrote source into a directory nothing collects
— the phase then delivers nothing, and looks like an agent that did no work.
The same skill instructed `file_read` / `file_write` / `shell`: ZeroClaw's
names, the exact ones `phase_task_text` was fixed to stop advertising after
five agents on a single mission spent 7.4k tokens describing the mismatch
instead of working. The prompt was corrected and the skill kept saying it.
Rewritten against what the code actually does, including the repo-less case
(`/mission/repo` exists, is collected as artifacts, has nothing to push).
THE CLASS, AND THE GUARD
The skills were never checked against the platform they describe. Nothing
compared them, so a skill could contradict the prompt it ships inside and
stay that way indefinitely — the same shape as PLAN_COMPLETE being
documented and never implemented.
Two tests in `skills_loader::contradiction_tests` now hold it: no skill may
name a repo path the platform does not mount, and none may instruct a tool
the agent's subprocess does not expose. The second matches backticked
instructions and skips corrective lines, so a skill may still WARN against
the wrong names — as this one now does. Both negative-controlled by
restoring the old wording.
AND THE CHECK THAT STARTED IT
`workspace-repo-commit-protocol` now has a Boundary check: writing outside
`/mission/repo` fails, and the message names the consequence — a phase that
delivers nothing — rather than just the wrong path.
docs/SKILL-USE-BASELINE.md records this as the fourth defect the
measurement found, and corrects the "next unit of work" note now that this
one is done.
Full workspace suite green: 106 binaries, zero build errors.
Co-Authored-By: Claude Opus 5 <[email protected]>
