mirror of
https://github.com/hanzoai/bot.git
synced 2026-08-07 00:32:19 +00:00
zeekay
61a4977aa3
CI / docs-scope (push) Successful in 3m36s
CI / checks (pnpm canvas:a2ui:bundle && bunx vitest run --config vitest.unit.config.ts, bun, test) (push) Skipped
CI / changed-scope (push) Skipped
CI / build-artifacts (push) Skipped
CI / release-check (push) Skipped
CI / checks (pnpm canvas:a2ui:bundle && pnpm test, node, test) (push) Skipped
CI / checks (pnpm protocol:check, node, protocol) (push) Skipped
CI / check (push) Skipped
CI / check-docs (push) Skipped
CI / checks-windows (pnpm test, node, 6, 2, test) (push) Skipped
CI / checks-windows (pnpm test, node, 6, 4, test) (push) Skipped
CI / skills-python (push) Skipped
CI / checks-windows (pnpm test, node, 6, 1, test) (push) Skipped
CI / checks-windows (pnpm test, node, 6, 3, test) (push) Skipped
CI / checks-windows (pnpm test, node, 6, 6, test) (push) Skipped
CI / android (./gradlew --no-daemon :app:testDebugUnitTest, test) (push) Skipped
CI / checks-windows (pnpm test, node, 6, 5, test) (push) Skipped
CI / android (./gradlew --no-daemon :app:assembleDebug, build) (push) Skipped
Hanzo CI/CD / cicd (push) Failing after 7m25s
CI/CD / cicd (push) Failing after 7m26s
deploy / build (push) Failing after 19s
CI / secrets (push) Failing after 8m6s
`dev` and `hanzo-mcp` were both on PATH and neither knew the other existed. The agent ran with its built-ins; the MCP server — fetch, web_search, web_read, browser, computer, git, exec, fs, code — sat there and nothing ever launched it. Measured in a live dev-class pod (digest sha256:4e5deb07) before this change: `dev mcp list` answered "No MCP servers configured yet." ONE LINE OF CONFIG, AND IT BELONGS IN THE IMAGE. A run that has to be TOLD where its tools are has them only when the caller remembers, and there are two callers. Stated here, every sandbox of this class has them on both execution paths with no code in either — so this is not an orchestration feature that a scheduler owns, it is a fact about the image, true at the layer where both binaries first exist. `dev mcp add` AND NOT A HAND-WRITTEN FILE, because the store is dev's and dev is the only thing that can name it. The CLI's help advertises `~/.code/config.toml` (inherited upstream wording) and it actually writes `~/.hanzo/dev/config.toml`. A file written to the documented path is read by nothing — which is the failure that LOOKS configured, so nobody goes looking. Asking the tool cannot be wrong, and it cannot go stale the day the path moves. STDIO, BECAUSE THAT IS WHAT THE SERVER SPEAKS, and this is the security property rather than a detail. hanzo-mcp 1.1.15 is JSON-RPC over stdin/stdout: it binds no port and listens on nothing, so the tool channel is a pipe between two processes inside one pod and there is no address on it to reach from outside. The pod's one channel out stays the Kubernetes exec subresource, which is the whole point of apps/sandbox deleting the in-pod HTTP daemon. Note the 1.1.12 source still reads `jsonrpc_http_server` on 127.0.0.1 — the SHIPPED binary is stdio, and the binary is what runs; trusting the checkout here would have bought an HTTP client for a server that never listens. Both asserts are build-time because a pod is the wrong place to discover this: `dev mcp list` must show the server, and hanzo-mcp must answer tools/list over a pipe. Output is captured to a file before grep rather than piped into `grep -q`, which closes the pipe on first match and leaves the server writing into a broken one — measured, and it is the difference between a clean assert and one that depends on pipefail being unset. Verified live in hanzo-sandboxes on hanzo-k8s: after the add, `dev mcp list` shows `hanzo hanzo-mcp`, and hanzo-mcp answers tools/list with 29 tools. `fetch` against example.com returned 200 from inside the gVisor pod, with the controls that make that mean something — link-local metadata and kms.hanzo.svc both unanswered from the same shell, and no service-account token mounted. The version moves 1.0.0 -> 1.0.1: the image's content changed, and a tag that gets rewritten is not a pin.
Hanzo Bot
Hanzo Bot is a personal AI assistant you run on your own machine. It sits behind a local gateway process and answers you on the chat apps you already use — WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Matrix, IRC, Teams and about a dozen more — so the assistant is reachable from your phone without anything of yours leaving your machine.
Install
Node 22 or newer:
npm install -g @hanzo/bot
That gives you two names for the same program, bot and hanzo-bot. Then run the
onboarding wizard, which walks through the gateway, the workspace, your channels and
skills, and installs the gateway as a launchd/systemd user service so it stays up:
hanzo-bot onboard --install-daemon
First things to try
hanzo-bot status # channel health, recent sessions
hanzo-bot agent -m "ship checklist" # one agent turn
hanzo-bot message send --target +15555550123 --message "Hi"
hanzo-bot dashboard # open the control UI
hanzo-bot doctor # health checks and quick fixes
hanzo-bot --help lists every command; each one takes --help of its own. To run the
gateway in the foreground instead of as a service, hanzo-bot gateway run --port 18789.
A note on models: the assistant reads your messages and acts on them, so prompt injection
is a real risk. Use the strongest current model you have access to. hanzo-bot models
manages selection and auth.
From source
git clone https://github.com/hanzoai/bot.git
cd bot
pnpm install
pnpm ui:build
pnpm build
pnpm hanzo-bot onboard --install-daemon
pnpm gateway:watch is the dev loop. There are also Compose files (compose.yml) and
Dockerfiles in the repository if you would rather run it in a container.
Docs
The documentation lives in docs/ in this repository — it is not published to a
website yet, so read it here or with hanzo-bot docs.
- Getting started · Onboarding · Quickstart
- Channels — one page per chat app, including how to connect it
- Concepts — the agent loop, sessions, memory, models, model failover
- CLI reference · Gateway · Installing and updating
- FAQ
SECURITY.md— the trust model, and why DM access is closed by defaultLLM.md— the deep reference for anyone working on the code
Release channels
Stable releases are tagged vYYYY.M.D and published to npm as latest. Prereleases go to
beta, and the moving head of main to dev when published. Switch with
hanzo-bot update --channel stable|beta|dev.
License
MIT — see LICENSE.