wanman: no npm package, a git clone, and a supervisor on port 3120

There is no package to install, only a clone and a build

The quickstart is the whole installation:

# Prerequisites: Node 20+, pnpm 9+, git, a logged-in Claude Code or Codex CLI.
git clone [email protected]:chekusu/wanman.git wanman.dev
cd wanman.dev
pnpm install
pnpm build

# Run from source; no npm package publish is required.
pnpm --filter @wanman/cli exec wanman takeover /path/to/any/git/repo

The comment on the last line is the point. The root `package.json` is named `wanman-dev`, marked `"private": true`, and sits at version `0.1.0`, so there is nothing to install from a registry and no release to wait for. The repository also has no GitHub releases. There is a fallback for people who want a single file: `pnpm --filter @wanman/cli standalone` followed by `node packages/cli/dist/wanman.mjs takeover /path/to/any/git/repo`. And if a `wanman` binary is already on your `PATH`, the command collapses to `wanman takeover .` from inside the target repository. Requirements are Node 20 or newer and pnpm 9, with `packageManager` pinned at `[email protected]`.

Each agent is a real CLI subprocess with its own worktree and home

The isolation claim is the load-bearing part of the design. Every agent runs as an actual Claude Code or Codex CLI subprocess, and you bring your own CLI authentication, because wanman orchestrates spawning, prompting, and lifecycle rather than calling a model API. Each child is bound to a per-agent git worktree and a per-agent `$HOME`, stated as the reason agents never mutate your dirty checkout or your shell profile. The architecture is three boxes:

+----------------+          +--------------------+          +-----------------+
|  wanman CLI    |  JSON    |  Supervisor        |  spawn   |  Agent process  |
|  (host shell)  | ---RPC-->|  (local process)   | -------> |  (Claude/Codex) |
|                |  /rpc    |  message/context/  |          |  per-agent $HOME|
|                |          |  task/artifact     |          |  per-agent wt   |
+----------------+          +--------------------+          +-----------------+

The command that starts all of this is called `takeover`, and it is pointed at a git repository path. So the shape of the tool is: you point an autonomous matrix at your working copy, and the per-agent worktrees are what keeps that from being a single shared directory with several writers.

The lifecycle that preserves context is rejected on Codex at startup

Agent definitions live in one JSON file, and each entry carries a `lifecycle` with three legal values. `24/7` is a continuous respawn loop. `on-demand` sits idle until triggered. `idle_cached` also sits idle, but preserves the prior Claude `session_id` across triggers through `claude --resume`, so context survives the idle period instead of restarting cold. That third value is explicitly Claude-only, and pairing it with `runtime: codex` in the config, or with `WANMAN_RUNTIME=codex` in the environment, is rejected at startup because Codex has no equivalent resume mechanism in this runtime. The adapter is selected by `WANMAN_RUNTIME`, where `claude` is the default, with `WANMAN_MODEL`, `WANMAN_CODEX_MODEL`, and `WANMAN_CODEX_REASONING_EFFORT` as per-runtime overrides and `WANMAN_CODEX_FAST` as a switch that biases the Codex adapter toward lower-latency defaults.

Five object types make up the working vocabulary

The CLI is a table of nouns rather than a set of verbs, which is the clearest signal of how the runtime thinks. `wanman task` manages a task pool with `create`, `list`, `get`, `update`, and `done`, and supports `--after` dependencies. `wanman initiative` covers long-lived efforts with `create`, `list`, `get`, and `update`. `wanman capsule` handles change capsules and adds a `mine` subcommand. `wanman artifact` stores and retrieves structured artifacts with `put`, `list`, and `get`. `wanman hypothesis` tracks hypotheses through status transitions. Around those sit the plumbing commands: `send` with `--steer` to interrupt a target, `recv` to drain and mark messages delivered, `agents` to list states, `context get` and `context set` for shared key/value state, `escalate` to reach the CEO agent, `watch` to live-stream activity, and `run <goal>` for a one-shot matrix. There is also `skill:check [path]`, which validates that skill documentation references only CLI commands that actually exist.

The supervisor is a local process holding five stores

A `wanman <subcommand>` invocation speaks JSON-RPC 2.0 to a Supervisor process, and `WANMAN_URL` points the CLI at it with a default of `http://localhost:3120`. `WANMAN_AGENT_NAME` identifies the current agent and doubles as the default sender and receiver inside agent processes. The Supervisor owns the message store, the context store, the task pool, and the artifact store, and it spawns one child process per agent. State lands on disk in the agent configuration file rather than in a default location chosen for you: `dbPath` is `.wanman/wanman.db`, `port` is `3120`, and `workspaceRoot` is `.wanman/agents`, so both the database and the worktrees live inside the repository you took over unless you move them. `WANMAN_SKILL_SNAPSHOTS_DIR` overrides where skill-activation snapshots are materialised, defaulting to a sibling of the shared-skills directory and falling back to `$TMPDIR/wanman-skill-snapshots`. For memory across runs there is an optional `@sandbank.dev/db9` brain adapter.

Isolation at scale and role generation are hosted, not in the repository

The open runtime and the product behind wanman.ai are described separately, and the split is not cosmetic. The hosted edition runs free on Sandbank Cloud's sandbox cloud and adds four things the local repository does not: each agent runtime group isolated in its own sandbox environment for large-scale, high-concurrency task execution; dynamic configuration of agent roles, including automatically extracting roles from agent role catalogues found on the internet; dynamic skill self-evolution; and db9-powered global search and story retrieval. The name comes from the Japanese ワンマン電車, a train run by one driver without a conductor, and the stated design goal is the same in spirit, with the human stepping back to an observer role while the matrix runs from every angle. Note that db9 appears in both lists, as an optional local memory adapter here and as hosted global search there.

FinOps reads your credential inventory and your Stripe balance

There is an experimental `@wanman/finops` toolkit in the monorepo, and it is the most unusual thing in the package list. Its four capabilities are an API credential inventory, provider cost sync, Stripe revenue sync, and product or company ROI summaries. That is a scope beyond agent orchestration: it enumerates which credentials exist on the machine, reads what providers are costing, and pulls revenue figures from Stripe to produce a return-on-investment view. It runs as a local review app with `pnpm --filter @wanman/finops dev -- --host 127.0.0.1 --port 4173`, which at least keeps it bound to the loopback interface rather than a routable address. It is labelled experimental, and given that it touches credential inventories and revenue data it is the component to read the source of before enabling.

Trilingual docs and a turbo monorepo at version 0.1.0

The root is a pnpm workspace: `packages/`, `pnpm-workspace.yaml`, `pnpm-lock.yaml`, `turbo.json`, `vitest.workspace.ts`, `tsconfig.base.json`, `docs/`, and `.github/`. Scripts are all turbo fan-outs, so `build`, `typecheck`, and `test` run across every package through `turbo build`, `turbo typecheck`, and `turbo test`, with devDependencies on `turbo ^2.3.0`, `typescript ^5.7.0`, `vitest ^4.0.18`, `@vitest/coverage-v8`, and `tsx`. Documentation is triplicated in English, Japanese, and Chinese, and the contribution guide exists in all three as `CONTRIBUTING.md`, `CONTRIBUTING.ja.md`, and `CONTRIBUTING.zh.md`, which is a rare amount of localisation effort for a 0.1.0 project. Against that, the last push to `main` is 2026-06-14 and the repository has no GitHub releases, so the version number is the only handle on what you have.

Editorial conclusion

wanman is interesting for one specific reason: it does not reimplement an agent, it drives the CLIs you already authenticate against, and it gives each one a worktree and a home directory so a matrix of them cannot trample the repository you are sitting in. The CLI-first surface is genuinely complete, with task, initiative, capsule, artifact, and hypothesis stores that other agent runners leave implicit. Before adopting it, weigh three things. You are running several real coding agents against your machine, and the tool that makes that safe, per-agent isolation, is exactly what you will want to verify rather than assume. The lifecycle value that preserves context across idle periods works on Claude only and is rejected at startup on Codex. And the isolation-at-scale and role-generation features are sold as hosted capabilities on wanman.ai, so the open repository gives you the local runtime rather than the full product.

Frequently asked questions

Official sources

1. chekusu/wanman on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README