clawmates

905 Commits 5 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Omar SobhandClaude Opus 5	53da4d7e6d	fix(runtime): a mission could not build the repo it was given deploy / test (push) Successful in 4m20s Details deploy / build (push) Successful in 5m21s Details `clawmates-runtime` shipped with `gcc` and `make` but no `cmake`, no `g++` and no `python3-dev`. Measured on clawhdf5, three probes: no cmake → "is `cmake` not installed?" exit 101 after 13s no python3-dev → "cannot find -lpython3.11" exit 101 at link with both → cargo test PASSES exit 0 after 69s This is not only the delivery gate. The AGENTS run in this image, so a coding phase was writing Rust it had no way to compile or test — which reframes the last run's 11 agent commits as unverifiable by construction. `images/agent-toolchain/Dockerfile` (the microVM path) has had `cmake build-essential` all along, and its own header warns about precisely this: "if `cargo` is present in one image and absent in another, the same mission passes or fails depending on which backend it landed on, and nothing says why." Both images now install the same set — it was missing `python3-dev` too. `images/runtime-toolchain.Dockerfile` is a thin local overlay so the laptop can run today without recompiling zeroclaw from the fork; it is meant to be deleted once a runtime image built from the corrected deploy/ Dockerfile is published. Also: a build failure is no longer reported as a red suite. Both are cargo exit 101, and `verify_tests` mapped every non-zero to `Failed(code)` — so a missing toolchain was recorded as the USER's tests failing. It now returns `CouldNotRun` with the reason when the output shows a compile or link failure. Deliberately narrow: a failing `assert!` still reads as red, because letting broken code past `on_green_tests` is the expensive direction to be wrong in. Both directions are pinned by tests built from today's two real samples. And the coding phase finally has a loop: `research_and_code.toml` declared `loop = "until_no_more_int_items"`, which `phase_config.rs` lists as DECLARED_BUT_UNREAD. Iteration is driven by `max_iterations` + `done_when`, and with `max_iterations = 1` and no `done_when` the phase ran ONCE and was never judged — reporting `completed` whatever it produced. Now 3 passes against a stated goal, wording per the measured rule (say what the tree must CONTAIN). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-16 11:02:07 -07:00
Omar SobhandClaude Opus 5	ebdba34da6	feat(fleet): B4.6 — a microVM reaches the API through a vsock CONNECT proxy, with an allow-list The guest still has no network interface, and now that is the design rather than a gap. Its only route out is an HTTP CONNECT proxy: agent CLI -> 127.0.0.1:3128 in the guest -> vsock 9002 -> a per-VM Unix socket on the host -> TLS to an allow-listed host. Why not TAP + iptables, which is what the Firecracker write-ups do — measured, not argued: - `ip tuntap add` is DENIED to the daemon user (needs CAP_NET_ADMIN), so TAP would need root to pre-provision devices, the same privilege detour the loop-mounted rootfs already forced. - tank's FORWARD policy is DROP with Docker and Tailscale chains, so rules would have to be inserted at position 1; appended ones die silently. - a leaked TAP is a new class of host litter to reap. CONNECT needs no privilege at all and is better on the merits: the client hands us the HOSTNAME, so resolution happens host-side and the guest needs no DNS or resolv.conf; the allow-list is by name, not address; and nothing in the guest can reach the network except through one function. The guest end parses nothing and enforces nothing, so a compromised agent cannot argue with the policy. Rests on one measured fact: `claude` honours HTTPS_PROXY. With the proxy at a closed port, `claude -p` fails ConnectionRefused instead of answering. THE RESULT: a real agent turn now completes inside a VM with no network card, on subscription auth — `claude -p` replies VM-OK. The selftest asks for it whenever CLAUDE_CODE_OAUTH_TOKEN is present and SKIPS loudly when it is not, since it spends a little of the plan. The audit log earns its keep immediately: during that turn the proxy logged `egress DENIED http-intake.logs.us5.datadoghq.com` — the CLI's telemetry, which the mission container permits today without anyone deciding to. Three bugs found by the checks rather than by review: - `env_pairs` returned early when a caller sent no env, so the proxy address was never added and `curl` in a VM with a working tunnel reported "Could not resolve host". Absent env means "the caller sent none", not "this command needs no environment". - the deny check PASSED for the wrong reason — DNS was failing, so nothing was refused by the allow-list at all. It now requires a 403 from the proxy, so it cannot go green on a broken tunnel. - `host_allowed` accepted `evil.test/api.anthropic.com`, which ends with an allowed suffix. Hostnames are now validated against a character class, which also refuses IP literals so an address cannot sidestep a list of names. - `BufReader::into_inner()` discards buffered bytes: wrapping the stream twice would have dropped the start of the TLS handshake and stalled a tunnel that looked established. One reader now spans the request, and anything buffered past the headers is forwarded as payload. `iproute2` is in agent-toolchain because it is load-bearing: the guest's `lo` starts DOWN, and while it is down a listener on loopback BINDS and then refuses every connection with ENETUNREACH. fcagent finds `ip` by absolute path — as pid 1 its PATH comes from the kernel, and execvp's fallback excludes /usr/sbin, where Debian puts it. Egress needs both ends up, so `create` reports `egress` and the guest's `ping` reports its own half. A VM without it is legal but never silent. Verified on tank: 16/16 with backend=claude (create 1428 ms), 12/12 on the default rootfs, no leaked processes, VM dirs or proxy sockets. 457 tests pass, clippy clean. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-05 12:44:59 -07:00
Omar SobhandClaude Opus 5	0c291ed1bb	feat(fleet): B4.4a — a real agent-claude microVM image, and a check that it has an agent in it The only rootfs on this track came from clawmates/agent-terminal:dev. Mounted, it held git and nothing else: no claude, no node, no cargo. A VM booted from it looks perfect and cannot run a mission, so B4.5 could have been written and never verified. images/agent-toolchain — the shared mission toolchain (node 22, git, rust + cargo-audit, gitleaks/trivy/semgrep, tea/gitea-mcp), lifted from the proven deploy/clawmates-runtime image minus the zeroclaw daemon: a microVM mission runs the direct-session model, so there is no daemon to host. A base image rather than three self-contained Dockerfiles because this layer is ~3 GB and the real risk is scanner and toolchain versions drifting between per-CLI images — the evaluator runs the project's own suite to check a claim, so `cargo` present in one image and absent in another makes the same mission pass or fail by backend with nothing saying why. images/agent-claude — plan A6, first of three: the pinned CLI and its env contract only, so bumping Claude Code does not rebuild the toolchain and cannot disturb agent-kimi / agent-glm. HOME=/root with an empty .claude for B4.4 to inject into; no ANTHROPIC_API_KEY, since it silently overrides the subscription OAuth we already pay for. Both the builder and the node selftest now ASK the guest for the CLI the image is named for, instead of trusting the name. `required_cli` maps claude/kimi/glm to a probe; an unrecognised backend reports unchecked and prints SKIP rather than passing quietly. Verified on tank: - rootfs-claude.ext4 boots; git, node, cargo, a real git commit all work - `claude --version` → 2.1.220 over vsock, in both the builder and `--vm-selftest` (11/11, create 1498 ms) - negative control: the same builder run against agent-terminal with FC_CLI forced reports `cli rc=127 claude: not found` and exits 1, so the green result above is a measurement and not a default - `claude -p hello` fails with "Not logged in · Please run /login" — the CLI runs headless in the VM, and B4.4 only has to supply the credential - no leaked firecracker processes or vm dirs afterwards 437 tests pass, clippy clean. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-05 11:33:07 -07:00

Author

SHA1

Message

Date

Omar SobhandClaude Opus 5

53da4d7e6d

fix(runtime): a mission could not build the repo it was given

deploy / test (push) Successful in 4m20s

Details

deploy / build (push) Successful in 5m21s

Details

`clawmates-runtime` shipped with `gcc` and `make` but no `cmake`, no `g++` and
no `python3-dev`. Measured on clawhdf5, three probes:

  no cmake        → "is `cmake` not installed?"        exit 101 after 13s
  no python3-dev  → "cannot find -lpython3.11"          exit 101 at link
  with both       → cargo test PASSES                   exit 0 after 69s

This is not only the delivery gate. The AGENTS run in this image, so a coding
phase was writing Rust it had no way to compile or test — which reframes the
last run's 11 agent commits as unverifiable by construction.

`images/agent-toolchain/Dockerfile` (the microVM path) has had `cmake
build-essential` all along, and its own header warns about precisely this:
"if `cargo` is present in one image and absent in another, the same mission
passes or fails depending on which backend it landed on, and nothing says why."
Both images now install the same set — it was missing `python3-dev` too.

`images/runtime-toolchain.Dockerfile` is a thin local overlay so the laptop can
run today without recompiling zeroclaw from the fork; it is meant to be deleted
once a runtime image built from the corrected deploy/ Dockerfile is published.

Also: a build failure is no longer reported as a red suite. Both are cargo exit
101, and `verify_tests` mapped every non-zero to `Failed(code)` — so a missing
toolchain was recorded as the USER's tests failing. It now returns
`CouldNotRun` with the reason when the output shows a compile or link failure.
Deliberately narrow: a failing `assert!` still reads as red, because letting
broken code past `on_green_tests` is the expensive direction to be wrong in.
Both directions are pinned by tests built from today's two real samples.

And the coding phase finally has a loop: `research_and_code.toml` declared
`loop = "until_no_more_int_items"`, which `phase_config.rs` lists as
DECLARED_BUT_UNREAD. Iteration is driven by `max_iterations` + `done_when`, and
with `max_iterations = 1` and no `done_when` the phase ran ONCE and was never
judged — reporting `completed` whatever it produced. Now 3 passes against a
stated goal, wording per the measured rule (say what the tree must CONTAIN).

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-08-16 11:02:07 -07:00

Omar SobhandClaude Opus 5

ebdba34da6

feat(fleet): B4.6 — a microVM reaches the API through a vsock CONNECT proxy, with an allow-list

The guest still has no network interface, and now that is the design rather than
a gap. Its only route out is an HTTP CONNECT proxy: agent CLI -> 127.0.0.1:3128
in the guest -> vsock 9002 -> a per-VM Unix socket on the host -> TLS to an
allow-listed host.

Why not TAP + iptables, which is what the Firecracker write-ups do — measured,
not argued:
  - `ip tuntap add` is DENIED to the daemon user (needs CAP_NET_ADMIN), so TAP
    would need root to pre-provision devices, the same privilege detour the
    loop-mounted rootfs already forced.
  - tank's FORWARD policy is DROP with Docker and Tailscale chains, so rules
    would have to be inserted at position 1; appended ones die silently.
  - a leaked TAP is a new class of host litter to reap.
CONNECT needs no privilege at all and is better on the merits: the client hands
us the HOSTNAME, so resolution happens host-side and the guest needs no DNS or
resolv.conf; the allow-list is by name, not address; and nothing in the guest can
reach the network except through one function. The guest end parses nothing and
enforces nothing, so a compromised agent cannot argue with the policy.

Rests on one measured fact: `claude` honours HTTPS_PROXY. With the proxy at a
closed port, `claude -p` fails ConnectionRefused instead of answering.

THE RESULT: a real agent turn now completes inside a VM with no network card, on
subscription auth — `claude -p` replies VM-OK. The selftest asks for it whenever
CLAUDE_CODE_OAUTH_TOKEN is present and SKIPS loudly when it is not, since it
spends a little of the plan.

The audit log earns its keep immediately: during that turn the proxy logged
`egress DENIED http-intake.logs.us5.datadoghq.com` — the CLI's telemetry, which
the mission container permits today without anyone deciding to.

Three bugs found by the checks rather than by review:
  - `env_pairs` returned early when a caller sent no env, so the proxy address
    was never added and `curl` in a VM with a working tunnel reported "Could not
    resolve host". Absent env means "the caller sent none", not "this command
    needs no environment".
  - the deny check PASSED for the wrong reason — DNS was failing, so nothing was
    refused by the allow-list at all. It now requires a 403 from the proxy, so it
    cannot go green on a broken tunnel.
  - `host_allowed` accepted `evil.test/api.anthropic.com`, which ends with an
    allowed suffix. Hostnames are now validated against a character class, which
    also refuses IP literals so an address cannot sidestep a list of names.
  - `BufReader::into_inner()` discards buffered bytes: wrapping the stream twice
    would have dropped the start of the TLS handshake and stalled a tunnel that
    looked established. One reader now spans the request, and anything buffered
    past the headers is forwarded as payload.

`iproute2` is in agent-toolchain because it is load-bearing: the guest's `lo`
starts DOWN, and while it is down a listener on loopback BINDS and then refuses
every connection with ENETUNREACH. fcagent finds `ip` by absolute path — as pid 1
its PATH comes from the kernel, and execvp's fallback excludes /usr/sbin, where
Debian puts it.

Egress needs both ends up, so `create` reports `egress` and the guest's `ping`
reports its own half. A VM without it is legal but never silent.

Verified on tank: 16/16 with backend=claude (create 1428 ms), 12/12 on the
default rootfs, no leaked processes, VM dirs or proxy sockets. 457 tests pass,
clippy clean.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-08-05 12:44:59 -07:00

Omar SobhandClaude Opus 5

0c291ed1bb

feat(fleet): B4.4a — a real agent-claude microVM image, and a check that it has an agent in it

The only rootfs on this track came from clawmates/agent-terminal:dev. Mounted,
it held git and nothing else: no claude, no node, no cargo. A VM booted from it
looks perfect and cannot run a mission, so B4.5 could have been written and
never verified.

images/agent-toolchain — the shared mission toolchain (node 22, git, rust +
cargo-audit, gitleaks/trivy/semgrep, tea/gitea-mcp), lifted from the proven
deploy/clawmates-runtime image minus the zeroclaw daemon: a microVM mission runs
the direct-session model, so there is no daemon to host. A base image rather
than three self-contained Dockerfiles because this layer is ~3 GB and the real
risk is scanner and toolchain versions drifting between per-CLI images — the
evaluator runs the project's own suite to check a claim, so `cargo` present in
one image and absent in another makes the same mission pass or fail by backend
with nothing saying why.

images/agent-claude — plan A6, first of three: the pinned CLI and its env
contract only, so bumping Claude Code does not rebuild the toolchain and cannot
disturb agent-kimi / agent-glm. HOME=/root with an empty .claude for B4.4 to
inject into; no ANTHROPIC_API_KEY, since it silently overrides the subscription
OAuth we already pay for.

Both the builder and the node selftest now ASK the guest for the CLI the image
is named for, instead of trusting the name. `required_cli` maps claude/kimi/glm
to a probe; an unrecognised backend reports unchecked and prints SKIP rather
than passing quietly.

Verified on tank:
  - rootfs-claude.ext4 boots; git, node, cargo, a real git commit all work
  - `claude --version` → 2.1.220 over vsock, in both the builder and
    `--vm-selftest` (11/11, create 1498 ms)
  - negative control: the same builder run against agent-terminal with
    FC_CLI forced reports `cli rc=127 claude: not found` and exits 1, so the
    green result above is a measurement and not a default
  - `claude -p hello` fails with "Not logged in · Please run /login" — the CLI
    runs headless in the VM, and B4.4 only has to supply the credential
  - no leaked firecracker processes or vm dirs afterwards

437 tests pass, clippy clean.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-08-05 11:33:07 -07:00