An independent, unofficial NanoClaw distribution
One narrow, guarded passage between your agents and everything they can touch.
Isthmus is NanoClaw — the same host, channels, and skills you already run on your own laptop or server — with an independently-enforced Go trust-kernel standing behind it. Nanogo ring-fences what your agent can touch: guard, mount, and egress decisions are enforced from a separate process, so neither a compromised host nor a compromised agent can grant itself privileges nanogo hasn't independently verified.
What changes
Same day-to-day experience. A different trust boundary underneath it.
Isthmus doesn't touch NanoClaw's channels, skills, templates, or agent runtime — installing and using it looks identical day to day. What's different sits below that: a second, independently-enforced layer standing behind the TypeScript host.
| Dimension | Upstream NanoClaw | + Isthmus |
|---|---|---|
| Enforcement | ||
| Privileged-decision boundary | –Enforced by the TypeScript host itself | +Independently-enforced Go kernel (nanogo) mediates every Docker / filesystem / network call, in a separate process |
| Egress lockdown | –Not present | +Blocks agent-container access to cloud-metadata & link-local ranges, a known credential-theft path (Linux) |
| Multi-turn reply routing | –Fixed via a turn-queue rewrite bundled with a provider-contract migration | +Same bug, fixed independently with a narrower mechanism — no shared code |
| Testing & CI | ||
| Behavior-fixture harness | –— | +60+ contracts pin real TypeScript guard/routing/delivery behavior byte-for-byte before any Go port |
| CI against live infrastructure | –— | +5 of 18 CI jobs run the kernel against a real Docker daemon, not a mock |
| Fuzzing & coverage floors | –— | +Coverage-guided fuzz targets, plus coverage and performance gates |
| Supply-chain scanning | –Base tooling | +pnpm-audit + bun-audit (baseline-gated) + go-vulncheck + semgrep + Dependabot across 4 ecosystems |
| Operations | ||
| Diagnostics | –— | +nanogo status / doctor / trace / security-check — health, remediation, and content-free request tracing |
| Ecosystem — channels, skills, templates | Full ecosystem | =Unchanged. Same install, same day-to-day behavior |
Sourced from Isthmus's own ADR series and CI configuration — see the README for citations on every row.
Architecture
The kernel sits behind the host, not wrapped around it.
Everything above the compatibility boundary is untouched NanoClaw. Everything below it — the point where a Docker, filesystem, or network call actually happens — is forced through one Go process before it can execute.
A compromised or buggy TypeScript caller can't bypass this by asking nicely — the validators run inside a separate Go process regardless of what the caller asserts. Everything above the boundary — the entire NanoClaw ecosystem you'd install skills for — is untouched and keeps tracking upstream normally.
Hardening
What building and operating this kernel actually surfaced.
Not a feature list — a record of what real, adversarial scrutiny of this codebase turned up, and what was built in response.
No upstream equivalent
Guard decisions, mount security, egress verification, and a handful of liveness decisions run inside a separately-tested Go binary the host reaches over a local Unix socket — not trusted to the TypeScript process itself.
Closing a known SSRF path
Blocks outbound access to cloud-metadata and link-local ranges. Getting it enforced correctly took several passes: a wiring gap that silently dropped it was found and closed, and the kernel now refuses to start if it can't actually enforce the block.
ADR-024 · ADR-025 · ADR-026 · ADR-028Built independently, not ported
Upstream fixes stale multi-turn reply routing with a turn-queue rewrite. Isthmus solves the same bug with a narrower, independently-designed mechanism — no shared data structures or timing changes.
60+ behavior contracts
A differential-fixture suite pins real TypeScript guard/routing/delivery behavior byte-for-byte before anything is ported — so every Go decision function is checked against NanoClaw's actual behavior, not a guessed spec. It's already found and fixed two real bugs.
Sized for a trust boundary
18 distinct jobs, several required. Five run the kernel against a real Docker daemon. Independent supply-chain scanning on both JS runtimes, Go vulnerability checks, static analysis, coverage and performance floors, coverage-guided fuzzing.
Tools NanoClaw doesn't ship
status, doctor (seven independent checks, concrete remediation), trace (content-free request tracing), and security-check — 60+ test cases across these alone.
Who this is for
A genuine, narrow improvement — not a blanket upgrade.
Its value scales with what your installation is actually exposed to.
Stronger candidate if…
- Real credentials or production/financial-system access are reachable from an agent's container or mounts
- Skills or MCP tools have outbound network access alongside sensitive local data
- More than one agent or messaging identity shares a host
- A 24/7 assistant ingests untrusted inbound content — DMs, email, scraped pages
Lower need if…
- Low-stakes personal use — a reminders bot, a weather query agent
- No credentials or production access reachable from the agent
- Inbound messages only from people you already trust
- NanoClaw's existing container isolation already matches your real risk
The risk this addresses is real, with documented precedent — CVE-2026-27002-class mount bypasses, real supply-chain compromises — and it scales with what's actually reachable from your agents.
Try it
Check your exposure before you install anything.
Scan your current install
Free, read-only, no install required. Works against plain NanoClaw too.
npx isthmus-scan
Install the kernel
Get nanogo running and start the host.
See docs/quickstart.md
Read before you install
The rollback runbook — what to expect, how to go back.
docs/rollback-runbook.md
macOS and Linux, MIT-licensed.
Windows users run under WSL2 — same as plain NanoClaw requires.