Colonizer v0.2.8

Before you update

• Fixes running colonies: Colonies parked by the daily PR cap resume: the cap is now off unless you set one. (#910)

Colonizer v0.2.8

The daily pull-request cap is off by default, and parked colonies resume

Update, and colonies parked by the daily PR cap carry on by themselves.

v0.2.7 capped every repository at 5 opened pull requests per UTC day by default. That cap is now
off unless you set one (#910, #1118). Colonies already parked with
repo_pr_rate_limit are requeued within a few minutes of the update, with their worktree as they
left it, instead of waiting for the UTC day to roll over.

To keep a cap:

• for every repository, set max_prs_per_day in the publish settings;
• for one repository, set max_prs_per_day under [colonizer] in its .colonizer/config.toml,
  which wins over the publish setting.

0 means no cap in either place.

A failed download is retried, not reported as failing tests

Before a colony's work is published, autopilot checks its claim by running the tests on a fresh
checkout. If that run died before the tests started, because rustup could not fetch a toolchain,
the crates.io or npm registry was unreachable, a DNS lookup failed or a connection was reset or timed
out, the colony used to be held as though its tests had failed. Now it is not
(#1117, #1119):

• The check is retried after 30 seconds, 2 minutes and 5 minutes.
• If every attempt fails the same way, the card says "verification could not run (network: …)",
  never "the completion claim was contradicted", and Create PR still publishes the colony.
• A run whose tests did start is judged as before, so a real test failure still holds at once.
• A Rust toolchain pinned in rust-toolchain.toml that the colony image already has is used as
  installed, so rustup no longer goes to the network for it.

A colony stuck in starting is flagged, and the watchdog is split up

A colony whose agent never connected after boot used to sit in starting forever, with no card,
no flag and no log line (#760, #1108). The watchdog now flags it as
stalled, so it shows in the cockpit's "needs you" list and in notifications:

• 15 minutes after the boot finished, if the agent still has not connected;
• 45 minutes after the colony was admitted, if the boot never finished at all.

A slow boot, such as a first colony pulling a large image, is left alone, and requests the colony
makes do not reset the clock. Such a colony is never nudged, since there is no agent to send a nudge
to. A colony parked on an exhausted provider keeps its quota card instead.

The same change splits the watchdog's source into a directory module (watchdog/mod.rs,
watchdog/defeat.rs and watchdog/tests.rs), because the file had grown past the 2000-line
limit. It is a pure move: nothing about how the watchdog behaves changes, beyond the new boot flag.

Everything else

• Colonies no longer get 403s from the crates.io CDN, PyPI or npm in a sandbox with no IPv6
  route (#946). A colony's VM has IPv4 only, but those registries also answer over IPv6.
  Every boot now tells the guest to prefer IPv4, and the colony's log says so when the guest has no
  IPv6. An /etc/gai.conf that already carries your own precedence line is left alone. Agents
  no longer need a third-party mirror to get past this.
• A "Built with" list (#944). colonizer about prints the products Colonizer is built
  with, each marked live or planned with a link; GET /api/built-with returns the same list
  as JSON. It is read from a copy shipped with the release, with no network call.
• The good-first-issues page says it is empty (#931) instead of sending newcomers to a
  list that is not there. The good first issue label is now the list.

Every entry is in
CHANGELOG.md.

Install

curl -fsSL https://colonizer.dev/install.sh | sh

Prebuilt bundles are published for Linux x86_64 (with KVM) and Apple Silicon Macs
(darwin-arm64); there is no Intel-Mac or Windows build. What one machine needs:

• Linux: /dev/kvm readable and writable by your user (sudo usermod -aG kvm "$USER", then log
  out and back in) and a native Claude Code install, which colonies run.
• Either platform: git, gh, curl and tar (with xz); on Apple Silicon the installer also
  fetches the Linux build of Claude Code a colony needs.

Run colonizer afterwards; it prints a sign-in link and opens it. The full walkthrough — install
options, first run, where things live, how to update — is in
docs/install.md.

Security status

Colonizer is alpha and not ready for unattended work on sensitive repositories, real credentials
included. An external audit of v0.1.3 (commit d89ce76, 17 September 2026) found four ways a
colony could cross into the host; they are filed as draft advisories (F01–F04) and are not fixed
yet, and its four release checkpoints (G1–G4) are all uncleared. Controls added since — scoped
tokens, remote-access fencing, sensitivity-aware routing, gateway audit lines, log and secret
redaction, path policy, egress and exec policies — do not close those findings, so attended work is
what the harness is good for today. The live status is
docs/audit.md and its tracking
issue (#91); report vulnerabilities privately
through SECURITY.md.

Prebuilt Colonizer for Linux x86_64 (with KVM) and Apple Silicon Macs, built from 36ed119.

curl -fsSL https://colonizer.dev/install.sh | sh

The installer checks the archive against SHA256SUMS. It fetches the Claude Agent SDK from the npm registry, and on a Mac the Linux build of Claude Code, from Anthropic's own channels: neither is in the release. Guide: https://colonizer.dev/docs/install

Each artifact, SHA256SUMS included, also carries a build-provenance attestation recording the commit that built it. Verify one with:

gh attestation verify colonizer-<platform>.tar.gz --repo Colonizer-dev/harness

Here is linux-x86_64 or darwin-arm64.

37ecf92073260a3dd0db133c997aea1c92fd0ff6458e83eb939b607196b4c0ba  colonizer-darwin-arm64.tar.gz
fd28b440a3c2401819034eb482846c4183c700f06e215b31ff10665af2e18b22  colonizer-linux-x86_64.tar.gz
12eeacb0c7248f4074b6343a1d787182a9ab18590837173dae19306ff33e85aa  install.sh