# Hanzo Dev The `dev` command: a coding agent for the terminal. ## Shape Hanzo owns the front door; upstream owns the engines. - `crates/hanzo-dev` is the binary. Its `main.rs` is the entire command surface, and every subcommand hands off to a library. Nothing is generated and no upstream source is compiled through an `include!`. - `crates/hanzo-config` picks the provider and the product home. `crates/hanzo-tui` is the Hanzo account behind /login, /logout, /auth and /status. `crates/hanzo-kai` is Kai. - `upstream/codex` is hanzoai/codex, the engines with Hanzo's commits on them. ## The loop the cloud drives The reasoning half of `dev` as a wasm module, with its Go host and the `wasm2go` build, lives in `hanzo-inc/dev`. Nothing here depends on it. ## Upstream `upstream/codex` is a submodule of **hanzoai/codex**, and the gitlink is the pin. That repository's `main` is ours: openai/codex's tree with Hanzo's commits on it. Its `upstream` remote is openai/codex. Crates are consumed straight from the checkout by ordinary path dependency, and the checkout is pristine: nothing rewrites it at build time, so `git -C upstream/codex status --porcelain` is empty after `make build` and `make test`. A bump is a merge, and its conflicts are git's: 1. In `upstream/codex`, on `main` (current with hanzoai/codex): `git fetch upstream && git merge upstream/main`. Resolve conflicts in git. 2. Read what the merge brought that the delta has not seen: new literals that say Codex (`git diff ORIG_HEAD -G'"[^"]*Codex' -- 'codex-rs/*.rs'`) and new `env!("CARGO_PKG_VERSION")` reads (`make test` fails on one, naming the file). Fix them as commits on `main`. 3. `make build test` here, push `main` to hanzoai/codex, then commit the gitlink. `make bump` prints those steps. The root `Cargo.toml`'s `[workspace.dependencies]` and `[patch]` tables mirror the fork's `codex-rs/Cargo.toml` (paths rewritten from the root), because patches apply only from the root workspace; refresh them on a bump. The fork builds and tests on its own (`cargo build` in `codex-rs`, `make test-upstream` here) and keeps its own `codex-rs/Cargo.lock`, as upstream does: it names no path outside its tree. Measured on the move from 11da6b9e to 3ee47c105 (288 upstream commits, 1,608 files), with the whole delta committed on the old base: the merge stopped on 5 files (one doc comment the delta rewords, two test fixtures and two strings upstream rewrote), and with upstream's side taken there, 16 files differed from what the old build-time rules made of the new tree: the strings and version reads upstream added, which step 2 finds. The delta on 3ee47c105 (`git log 3ee47c105..main` in `upstream/codex`): - `codex-rs/hanzo`, one crate: Dev's names and the TUI's defaults, `API_BASE`, `DEFAULT_MODEL`, `is_hanzo`, the model catalog, `model::pick` (the `/model ` match), the controller interface the loop consults (`controller::{Controller, Handle, Verdict, Card, Request, Shortlist}`) and `version`. Upstream crates read these; Dev's crates depend on this one, never the reverse. - Two hooks, each a no-op until a binary fills it, so with nothing registered the engines behave as upstream's: `codex_app_server::register(Extension)` adds an extension to every thread (process-global: the TUI and exec start the app server in process), and `codex_tui::register(Account { login, logout, show })` puts an account behind /login, /auth, /logout and /status (without one, /login and /auth are not offered). hanzo-dev's `main` registers `hanzo_kai::install` and `hanzo_tui::account` before anything starts. - `tui:`, `cli:`, `config:`, `core:`, `words:` the edits that were anchored strings: Dev's words and colors, `/model `, the published `mcp_cmd`, `plugin_cmd` and `doctor` (they belong upstream as a pull request), `.hanzo` homes, the controller's calls in the loop, Hanzo's catalog and reviewers. - `brand:` Dev's name in every user-facing string literal of non-test code. - `version:` the version, below. Dev reads only Hanzo's directories. Its home is `~/.hanzo/dev` (or `DEV_HOME`), a project's settings live in `/.hanzo/dev/`, and system ones in `/etc/hanzo/dev/`; a `.codex` beside them belongs to another product and is not read. Its server runs inside the process: upstream's shared background server is installed from a package directory Dev does not ship (`hanzo::BACKGROUND_SERVER`). A profile that names no provider is set to Hanzo at startup. `crates/hanzo-dev/tests/launch.rs` launches a bare `dev` in a terminal and holds all three. The version is the release's, set by hand in the root `Cargo.toml`'s `[workspace.package]`, in `npm/package.json` and in the tag, and `release.yml` refuses a tag the two manifests do not both say. hanzo-dev alone takes it: its `main` hands its own `CARGO_PKG_VERSION` to `hanzo::version::set`, and every upstream crate asks `hanzo::version::get()` at run time. Dev's libraries stay `0.0.0`. So a release recompiles hanzo-dev and the link, nothing beneath. `crates/hanzo-dev/tests/cli.rs` and `launch.rs` hold `--version`, the doctor and the TUI header to the version the binary was built as, and fail on any upstream read of its own. ## Never edit upstream by hand A change upstream hard-codes is a commit on hanzoai/codex `main`, made in `upstream/codex` and pushed there before the gitlink here moves; never a build-time rewrite, never an uncommitted edit in the checkout. Anything that need not live inside upstream's crates goes in a `hanzo-*` crate here. ## The Code fork just-every/code is reference, never a build input (its crates carry their own codex-core); its clone lives at `~/work/just-every/code`, and what was ported from it is recorded in `migration/`. ## Working here make build the dev binary make test the Hanzo suite make test-upstream hanzoai/codex's own suite against the pinned checkout make bump how to move upstream/codex forward make help everything `make build` is the check that must pass. Fix warnings as well as errors. ## The release cache Each release build runs rustc through sccache, and hanzoai/ci's `bin/cache` (pinned by commit as `CI_SHA` in `release.yml`) carries the objects, the registry's crate files and the git dependencies to the next run through the org's `ci-cache` bucket in cloud's `/v1/s3`. The IAM token comes from the KMS client pair inside the restore and save steps and is never exported, so no build script sees it. - Name `-`; key ``. The release's version is in the root manifest and the lock, so each release misses its key and restores `latest` for its name, whose objects serve every crate but hanzo-dev. - Only main and tags write, and only a key the store does not hold. Before a save the directory is cut to what that build touched: sccache bumps an object's mtime on a hit, and a crate file stays only if cargo unpacked it. - What compiles every release anyway: proc-macro and build-script crates, which sccache cannot cache, the crates the commit changed and those above them, hanzo-dev (it carries the version) and the link. Before the version became a run-time value the stamp changed every first-party crate's version, which is in both `-C metadata` and `CARGO_PKG_VERSION`, so all ~150 recompiled on every release; that is why Dev's libraries stay `0.0.0`. - Measured on dgx (its own target, two jobs, a busy host): cold, 1,046 crates in 59.6 minutes; the same release from an empty target dir with a warm cache, 6.7 minutes and not one Rust miss (1,109 hits), hanzo-dev's own compile and the link ~4 of them; a new version alone rebuilds hanzo-dev and nothing else (measured then with the version passed as `DEV_VERSION`, which reached the same one crate). - `sccache --show-stats` prints at the end of every Build step, pass or fail. ## Review and memory models Automatic approval review and memory extraction and consolidation name a model of their own. Upstream's ids are OpenAI's; api.hanzo.ai serves none of them. On the Hanzo provider (`hanzo::is_hanzo`, base URL `hanzo::API_BASE`) all three are `DEFAULT_MODEL`. The reviewer takes its preferred id only when the catalog serves it, else the parent's model, and off OpenAI only a listed entry is served: the bundled OpenAI entries ride along unlisted in every catalog, for lookups. So a LAN engine with no catalog of its own is reviewed by the model it runs. Guardian v2's sync reviewer runs on that same choice; its `CodexResponsesHeaders` model only scopes an OpenAI-backend header. `crates/hanzo-dev/tests/review.rs` holds both. ## Controller Kai is Dev's native controller, not an advisory service: it returns a validated operation or an explicit abstention, never advice. `crates/hanzo-kai` is the loop (`flow`), the ledger (`ledger`) and the tools they run. Search, saved actions and the shell classifier are hanzo-mcp's library (`hanzoai/mcp`, crate `hanzo-trigram` today); Dev links it and keeps the seams as traits (`find::Finder`, `decide::Transport`). - **Task state.** One per run: objective, workspace revision, pending actions, verification status. The loop owns it and each action's lifecycle. An expected outcome is never accepted because something predicted it: only the verifier's record (exit status, the tests, the diff) settles it. `beneficial` is never set at run time, only by a benchmark from a measured gain. - **Action.** `Action { id, task, revision, evidence, operation, preconditions, authorization, expected, verification, source }` plus status, milliseconds and result. `operation` is typed (`search`, `decide`, `mutate`, `generate`, `edit`, `test`, `revert`); `source` is `rule`, `kai`, `model` or `recover`. A saved typed operation is an action; a plan of actions is a workflow; a reusable validated result is the cache. Kai selects and binds an action's inputs and never writes shell. Status: eligible, attempted, completed, validated, selected, applied, verified, or ended early as abstained, rejected, timed_out, failed, escalated; each action records the path. - **Order of cheapness, per step.** An action that applies (one candidate, preconditions hold) runs with no Kai inference. Else Kai's structured decision, all of a state's questions in one request (`fix.site@1`: site, action, effort; `fix.turn@1`: next, done, correct, grounded, complete, risk). Else low-effort generation, then full-effort generation, then `recover`. Every transition is a ledger line with its reason (`fast`, `fallback`); no step waits on Kai when an action already applies. Each program has its own outage cooldown: one capability's timeout never disables another. - **Nothing waits that need not.** The first state's first call is begun the moment the state is ranked, beside the search (`flow::Ahead`, `zen::Zen::start`), against that state's revision. The search settling the task, or a kept step moving the state, cancels it; when the search settles nothing the call has had the search's time to answer, and the ledger's `generate` says how long (`ahead_ms`). A cancelled call closes its stream (the server stops writing it) and leaves a `cancelled` line in the spend file, its prompt counted at three characters a token at the ceiling rate; the ledger has a `cancel` line, never a `generate` one. An answer asked ahead is tried before any new call at its revision, and with one queued Kai is not asked `fix.turn@1`. - **Revision-bound.** Preconditions are checked immediately before execution; an edit invalidates every pending decision made against the old revision. A revision is the content of the files the run touched, and a revert returns to `base`. A cached result is keyed on what it depends on (files, symbols, tool versions, environment; uncommitted changes count), never on a commit. - **Recover proves progress.** A failed verification records the failure's fingerprint (paths, line numbers and ids normalized), the prior action, the resulting diff and the outcome. An edit that leaves fewer tests failing is progress and stays; the state is looked at again. The same fingerprint with no change of state makes `recover` pick a different action or escalate; it never replays the loop. - **Search** is one engine, tgrep (`hanzo-trigram`, in process). It puts the lines that spell the failure's messages and names into the ranking; `locate` ranks every function (kai-gateway's learned preflight weights, `locate::tests` hold its features to the gateway's). - **Fast path.** The action `mutate` tries generic token transforms (comparison and operator flips, constants off by one, arguments swapped, a condition inverted, a `return` dropped) at the best sites against the one visible test command, eight at once, capped in time; it names no repository, file or task. It solves single faults of that kind and nothing else. Past its 2.5 s cap it goes on while the call asked beside it has not answered, to 8 s (`mutate::LONGEST`): that wait is spent either way, and on a loaded host the cap cut 34 of 39 unsettled dev-split searches short of their candidates, the fix in the top four sites in 9 of them. A visible test too slow for the cap (its time x 1.5 > the cap) is narrowed to the failing tests it names (`mutate::screen`) instead of the search being skipped: lark's 18 s file runs its failing tests in 1.7 s, and the candidate picked is verified with the whole command in the tree as ever. A fast file narrowed ran 5% faster (two measurements, 13 and 19 tasks), not worth a second command there. - **The tests around the failing ones** (`wide`) run beside the visible test after an edit, and a failing visible test stops them. What failed among them before any edit is read only when they fail after it, with the files the run touched put back as they were for that read and then as they are (`flow::before`, ledger `lazy`): a run that passes shows nothing new, so on most tasks it is never read, and it never competes with the search for the CPU. - **A test run leaves nothing.** Files a run in the tree writes that git neither tracks nor ignores and that were not there before it are removed after it, with the directories they emptied (`tools::Litter`, ledger `sweep`): they are the run's, never the edit's. What `.gitignore` names is left alone, and so is a tree outside git. Hypothesis keeps its example database in the run's own temporary directory (`HYPOTHESIS_STORAGE_DIRECTORY`, unless the caller set it), so no run replays another's examples and none lands in the tree. - **Jobs** (not built): long work runs in the background and reports events into the same ledger. Start, progress, completion and verified outcome are four states; a finished process is not a finished task. - **Ledger.** `kai/ledger.jsonl` beside the trace, replayable: stable ids for every decision, fallback, execution and verification so time and cost are attributable; credentials and sensitive output redacted. - **Generation** is Zen or enso-flash over an OpenAI-compatible endpoint (`kai.toml` `[generate]`), called when needed, streamed so the first token and the last are both timed; a paid call is a line in the spend file with the model the server says served it, and the budget stops it. - **The edit's path from a model** (`zen.rs`, `edit.rs`, `flow.rs`). At Hanzo's API an edit is asked for as a strict JSON schema (`edits`, at least one, each `file`, `line`, `old`, `new`). `openai/gpt-6-sol` decodes under it; `enso-flash` is asked and may still think aloud before the JSON (700 to 900 tokens, so an answer that does not reason has 2,048 of room), but with at least one edit required it stopped answering `{"edits":[]}` (6 of 13 calls without, 0 of 19 with). A call that reasons has one cap of 16,384 for reasoning and answer together, at `reasoning_effort` low: a cap of 3,072 at medium lost five answers of ten to reasoning alone (finish `length`, 3,072 of 3,072 completion tokens reasoning, no text), where medium reasoned 221 to 3,106 tokens and low 58 to 1,001. Every call that reached the model is kept under `generate.calls` with its finish reason and usage, reasoning tokens apart; a call without text, or ended by the server with an error, is kept with its error, billed in the spend file, and asked again. `edit::parse` says which miss it is: no edits, JSON that does not read or is no edit, or no JSON. An answer refused for how it is written (it does not read, or its old text is not in the file) goes back to the model once, with the reason and the file's own lines where the edit said it stood (`stage: repair`); an escalated attempt that still has no edit goes to the generator once over the same prompt (`stage: fallback`, never an Anthropic model). Each is an action of its own in the ledger, the trace line lists every call (`generations`), and the edit is tested as ever: a parsed answer is not a solve. An answer of no edits is not said again (it costs the attempt, as before); `{"edits":[]}` from a model that names the file it would need to see is a context failure, not an output one. - **Kai's transport** is `decide::Transport`: HTTP `POST /v1/decisions` today. The local engine over ZAP on a Unix socket is the other implementation, and needs the engine to serve a `decisions` method (the engine's ZAP module and `hanzo-zap` 0.2.1 are stubs; `zapwire` is the working Rust ZAP wire). ## House rules - Hanzo service APIs use `https://api.hanzo.ai/v1/` exclusively. - Keep the upstream interaction model and animation; the branding is ours. - Keep Linux, macOS, and Windows working. - Upstream project names appear only in `NOTICE` — never in the README, the repository description, the CLI, or the interface. ## Runtime & Model Fixes (2026-10-07) - **Model metadata**: a model the fork's catalog (`hanzo::catalog`) knows (`enso-auto` among them) gets its window and modalities from the catalog, so it raises no "Unknown model ... fallback metadata" warning (hanzoai/codex `core:` commit, models-manager). - **Sandbox permissions**: a justification with no escalation asked for runs at the default permissions instead of failing the shell call (`core:` commit, core/src/tools/handlers). - **ChatGPT legacy plugins 401**: featured plugins are asked for only with a ChatGPT sign-in (`auth.uses_codex_backend()`; `core:` commit, core-plugins). - **Auth Symlink Guarantee**: `hanzo-config::ensure_parent_and_symlink` ensures `~/.hanzo/auth.json` is initialized with `{}` if absent before symlinking, preventing dangling `~/.hanzo/dev/auth.json`. - **Token Refresh Command**: `DEFAULT_CONFIG` includes dynamic token refresh configuration `[model_providers.hanzo.auth] command = "hanzo auth token", refresh_interval_ms = 600000` to prevent 60-minute JWT expiration mid-session.