zeekay c74dc19e97 fix(release): name the registry on every npm call
The 0.6.93 publish job got all the way to the end — notes verified, GitHub
release created with 28 assets, Homebrew formula published — and then died on
`npm whoami` with "npm auth failed", while the dedicated npm-auth-check job had
validated the very same token an hour earlier in the same run.

Both were right. They were talking to different registries.

The repo's root .npmrc sets `registry=https://pkg.hanzo.ai/`, and npm gives the
project file precedence over the user config that setup-node writes. So a bare
`npm whoami` at the repo root asks our own registry to validate an npmjs token.
pkg.hanzo.ai answers 200 with a body of `{}`. Older npm shrugged at that — which
is why this step passed for 0.6.92 eight hours earlier — and the npm that ships
with Node 24 reads it as "not logged in". The runners moved to Node 24 in
between; the deprecation notice is in both logs.

The publishes themselves were never affected, because each one runs `cd` into a
package directory and npm does not search parent directories for .npmrc — so
they used the user config and reached npmjs. That is a coincidence holding up
the supply chain, not a design.

So: name the registry on every npm call that talks to npmjs — whoami, publish,
and the `npm view` probes that decide whether a version is already published
and what the next version should be. Those last ones matter as much: they were
asking a proxy what npmjs contains, and the answer gates both the version bump
and the skip-if-already-published check.

Also stopped swallowing npm's own error in the publish job's whoami. The generic
"npm auth failed" message sent a real investigation toward the token, which was
fine the whole time.

Verified: cargo nextest run -p code-core --test hanzo_identity -> 4/4 pass;
the workflow still parses and all six jobs are intact.
2026-08-06 23:25:37 -07:00
2026-08-04 16:52:12 -07:00
2025-04-16 12:56:08 -04:00
2025-09-22 16:48:03 +02:00
2025-04-16 12:56:08 -04:00

Hanzo Dev

Hanzo Dev

Hanzo Dev is our coding agent. It runs in your terminal, reads and edits the repository you point it at, runs commands in a sandbox, and drives a browser when a task needs one. Models are served by Hanzo AI — enso and the zen5 family — over the metered gateway at api.hanzo.ai.

It ships inside the Hanzo CLI. hanzo dev is the command.

A session in progress
A session in progress
Reviewing a diff
Reviewing a diff
Driving a browser
Driving a browser
Several agents on one task
Several agents on one task

Install

curl -fsSL https://hanzo.sh | sh
hanzo auth login

hanzo auth login signs you in through Hanzo IAM and links the machine to your account. Then, from any repository:

hanzo dev

Give it the task on the command line to run headless instead:

hanzo dev "fix the failing tests in ./core and explain what was wrong"

Choosing a model

Model ids come from the gateway, which is the only authority on the catalog — there is no allowlist in the client.

hanzo dev --model enso          # our frontier model
hanzo dev --model enso-ultra    # the largest reasoning tier
hanzo dev --model zen5-coder    # tuned for code

Browse everything available with curl https://catalog.hanzo.ai/v1/models.

Backends

Hanzo Dev is the default and the one we build. The same session launcher can also drive two other agents if you already have them installed, so you can keep one set of habits across all three:

hanzo dev              # our agent (default)
hanzo dev claude       # or: hanzo code --claude
hanzo dev codex        # or: hanzo code --codex

hanzo dev is a spelling of hanzo code dev, not a second implementation — every spelling resolves through the same launcher.

Options

hanzo dev [OPTIONS] [BACKEND|TASK] [TASK] [-- <PASSTHROUGH>...]

  --model <MODEL>     Gateway model id, e.g. enso, enso-ultra, zen5-coder
  --backend <NAME>    dev (default) | claude | codex
  --brand <BRAND>     Tenant for auth: hanzo | lux | zoo | pars | bootnode
  --ask               Ask before each action instead of auto-approving (alias: --safe)
  --no-sandbox        Drop the sandbox and auto-approve. Per-invocation, never persisted
  --no-route          Call the backend's own model account instead of the metered gateway
  --no-mcp            Do not attach the Hanzo MCP toolset
  --project-mcp       Also load the repo's own .mcp.json servers (off by default — a repo is untrusted)
  --link / --no-link  Stream the session to Hanzo cloud, or never
  --resume <ID>       Resume a prior linked session by its cloud session id
  -c, --config <FILE> Use a specific config file
  -v, --verbose       Increase logging verbosity

Anything after -- is passed verbatim to the backend.

Two defaults worth knowing. Sessions run sandboxed and auto-approve inside that sandbox; --ask tightens it, --no-sandbox removes it. Model calls route through api.hanzo.ai so usage is metered on your Hanzo account; --no-route sends them to the backend's own account instead.

In a session

Type / for the full list. The ones you will reach for:

/plan       create a comprehensive plan (multiple agents)
/solve      solve a challenging problem (multiple agents)
/code       perform a coding task (multiple agents)
/auto       work autonomously on long tasks with Auto Drive
/agents     create and configure agents
/browser    open the internal browser
/chrome     connect to a running Chrome over CDP
/diff       show the git diff, including untracked files
/review     review your changes for potential issues
/undo       restore the workspace to the last snapshot
/branch     work on a branch in a worktree
/merge      merge the worktree branch back to the default
/model      choose model and reasoning effort
/reasoning  change reasoning effort (minimal/low/medium/high)
/theme      switch color themes
/status     session configuration and token usage
/limits     weekly and hourly rate limits
/mcp        manage MCP servers (status/on/off/add)
/init       write an AGENTS.md for this repository
/resume     resume a past session for this folder
/new        start a new chat

Full list with descriptions: docs/slash-commands.md.

Project context

Run /init in a repository and Hanzo Dev writes an AGENTS.md describing what it found. Edit that file — it is read at the start of every session in that directory, so it is where project conventions, architecture notes and "do not touch this" rules belong.

Tools

The Hanzo MCP toolset is attached by default: filesystem, shell, browser, and the rest of the Hanzo surface. Add your own servers with /mcp add, or per repository in .mcp.json — the latter is off unless you pass --project-mcp, because a repository you just cloned should not get to run a server with your session's key.

Documentation

Building from source

git clone https://github.com/hanzoai/dev.git
cd dev
./build-fast.sh

./build-fast.sh is the required check — it must pass cleanly, warnings included. See DEVELOPING.md and LLM.md for the workspace layout and the rules that apply inside it.

Contributing

Branch, make the change, make ./build-fast.sh pass, open a pull request. Bugs and feature requests: github.com/hanzoai/dev/issues.

License

Apache-2.0 — see LICENSE.

Lineage

Hanzo Dev is a fork of just-every/code, which is itself a fork of openai/codex. Both are Apache-2.0, and this repository preserves the upstream LICENSE and NOTICE. Hanzo Dev is not affiliated with, sponsored by, or endorsed by either project.

S
Description
No description provided
Readme Apache-2.0
1.4 GiB
Languages
Python 53.1%
Rust 33.6%
TypeScript 3.9%
JavaScript 3.8%
Shell 3.6%
Other 1.8%