Three published packages declared a console script named `hanzo`, competing with
the native CLI and with each other. Measured on a clean venv at hanzo==0.4.3:
`hanzo --help` printed hanzo-cli's program, not the one pkg/hanzo/README.md
documents. Renamed to `hanzo-py` and `hanzo-cli` — script named after its
distribution. Nothing is yanked; both packages still install and run.
- pkg/hanzo 0.4.4 — summary and README now say the CLI is a native binary
(curl -fsSL https://hanzo.sh | sh). Dropped the invented command tour
(`hanzo chat --model gpt-4`, `hanzo node start`, `hanzo router start` on
localhost:4000): none of those verbs exist in the program this package
installs. Kept the three library entry points, each import-checked.
- pkg/hanzo-cli 0.2.4 — `hanzo login` replaced with the native `hanzo auth login`
plus its own `hanzo-cli login`. Verified `hanzo iam users list` and
`hanzo kms secrets list` against the shipped v1.9.18 binary.
- pkg/hanzo-node 0.1.1 — states the two meanings of the name: the `hanzo-node`
COMMAND is a symlink to the Hanzo CLI; this package fetches a different binary
from hanzoai/node, which is private, so the download 404s for the public.
Documentation URL moved off docs.hanzo.ai/node (404) to hanzo.sh.
- root README (published as `hanzoai`) — `pip install hanzo` no longer advertised
as the CLI; model ids zen-coder -> zen5-coder (zen-coder is not in the catalog);
"2452 operations, 1798 schemas" dropped for the spec URL, since the live
surface is 1058 paths / 1465 operations / 1139 schemas.
Co-authored-by: Hanzo Dev <[email protected]>
is_authenticated() was `load_token() is not None` — a string-presence check
that returned True for the literal "fake.not.a.real.jwt". Every permission
decision downstream of it was therefore a lie. This makes the client side of
Hanzo auth actually work, end to end. Builds on the /v1/iam prefix already on
main; the endpoint paths were necessary but not sufficient.
hanzo_iam.tokens — the ONE credential judge. Verifies the signature against
the issuer's published JWKS plus exp/iss/aud, and fails CLOSED: an unreachable
JWKS is not a pass, because a client that cannot check a signature does not
know the token is good. Reason codes distinguish "expired" from "offline".
`alg: none` is absent from the accepted list by construction. An opaque API
key cannot be judged offline, so it is confirmed against userinfo rather than
assumed valid for being a non-empty string.
hanzo_iam.oauth — a real login: authorization code + PKCE (S256) over a
loopback redirect, with a deadline. Not the device grant, which would be the
better CLI UX: iam implements RFC 8628 fully and advertises it, but no PUBLIC
client is registered, so POST /v1/iam/oauth/device answers 401 invalid_client
for hanzo-cli, hanzo-app, hanzo-cloud and hanzo-console alike. Registering one
public app is the whole server-side fix; shipping a device path that always
401s would be a lie in code. The password grant is out for the same reason
(401 invalid_client without a secret), so `--no-browser` now prints the URL
instead of prompting for a password it cannot use.
The loopback listener binds a REGISTERED redirect_uri. iam compares
redirect_uri by exact string and does not apply RFC 8252 §7.3 port-agnostic
loopback matching, so a CLI cannot pick a free ephemeral port — the previous
code bound 8399 (cli) and 8398 (bot), neither registered, and /authorize
refused both with a bare 400 before the user saw a login page. It listens on
127.0.0.1 and ::1 because the registered URIs spell "localhost", and sets
SO_REUSEADDR because the previous callback sits in TIME_WAIT for ~60s and
would otherwise EADDRINUSE a second login on a port nothing is using.
hanzo_iam.store — keyring first, else an atomic 0600 file. The old path did
write_text() then chmod(0600), so with umask 022 a bearer token sat at 0644
between the two calls. Now it is created private and renamed into place. The
PaaS session cache goes through the same writer.
Two definitions of IAMConfig existed; models.py's was the one every client
imported, so the endpoint properties main had just fixed on config.py's were
dead code. One now, in config.py, plus jwks_uri and device_endpoint.
The bot and CLI login copies are gone; both call the one flow. whoami and
`hanzo bot login` no longer print claims from an unverified decode — that
rendered an attacker-chosen identity as fact.
The Team tool refuses instead of pretending: api.hanzo.ai/team is the
marketing SPA (200 text/html), so raise_for_status() passed and .json() blew
up. There is no Team API; HANZO_TEAM_URL stays as the seam for when one ships.
PaaS token exchange reports its real diagnosis: POST /v1/auth/login 404s while
/v1/org and /v1/user 401, so the API is up and gated but the exchange route is
not deployed at that edge. No client-side workaround exists, so it says so.
Tests fail against the old behaviour, which is the point: 5 session tests fail
against the shipped is_authenticated and 4 store tests fail against
write-then-chmod. 134 pass alongside main's KMS suite.
Co-authored-by: Hanzo Dev <[email protected]>
Same drift as the CLI, in all three packages: a hardcoded __version__ that no
longer matched pyproject.
hanzo_iam/__init__.py 1.1.1 vs pyproject 1.30.0 (29 minor versions apart)
hanzo_cli/__init__.py 0.1.0 vs pyproject 0.2.2
The hanzo_cli one was load-bearing: click's version_option reads it, so it is
the reason `hanzo --version` answered "0.1.0" — a release that never existed.
All three now resolve from the installed distribution, so there is one answer.
Patch bumps for the two packages changed in 68877409 (never a lazy major):
hanzo-cli 0.2.2 -> 0.2.3 entry point removed, __main__ added, PKCE, token path
hanzo-iam 1.30.0 -> 1.30.1 endpoint properties on the exported IAMConfig
Verified on a clean venv: __version__ == importlib.metadata.version for all
three, `hanzo --version` 0.4.4, `python -m hanzo_cli --version` 0.2.3, 58
commands. hanzo-iam 19/19; hanzo-cli's failures are unchanged live-service auth.
Co-authored-by: Hanzo Dev <[email protected]>
`hanzo` depends on `hanzo-cli`, and BOTH declared `[project.scripts] hanzo`.
Entry-point resolution is install-order dependent, so which CLI a user got was
a coin flip — and hanzo-cli kept winning. The result:
$ hanzo auth login
Error: No such command 'auth'.
So the "auth login is broken by Cloudflare 1010" story was real but unreachable:
users never got as far as the HTTP call, because the binary they had did not
have an `auth` command at all. Publishing that fix would have changed nothing.
One command, one owner:
- hanzo-cli drops its console script. `hanzo` is the ONE command.
- `paas` and `bot` are mounted into it — the only two groups with no equivalent.
`kms` is NOT mounted: `hanzo secrets` is a strict superset (audit/grant/
revoke/rollback/rotate/versions on top of the same get/list/set/delete), and
two commands for one concern is what we are removing.
- hanzo_cli grows a __main__ so it stays invocable as `python -m hanzo_cli`,
and its e2e suite targets that instead of whatever `hanzo` resolves to.
Endpoints, one definition:
- models.IAMConfig (the class the package EXPORTS) gains the HIP-0111 endpoint
properties. config.IAMConfig had them, but nothing imports that one — a
second same-named class nobody uses is how the legacy path survived.
- config.py + fastapi.py stop hand-assembling paths and read the constants.
- password_login posted to `/oauth/token`, which is not a 404: IAM serves a
200 text/html SPA catch-all for unregistered paths, so it received a login
PAGE and json() blew up on HTML. Verified: legacy 200 text/html vs canonical
401 application/json.
PKCE, because this is a public client:
- browser_login ships no client_secret, so the authorization code was the only
secret in the flow and it arrives over a plaintext loopback redirect. The SDK
already accepted code_challenge/code_verifier; the CLI simply never passed
them. RFC 8252 §8.1 / RFC 7636 S256.
Version, one source:
- pyproject said 0.4.4, __init__ said 0.3.47, cli.py said 0.3.48, and the
installed binary reported 0.1.0 — four answers, none right. Now resolved
from the installed distribution.
Verified on a clean venv: entry-point providers 2 -> 1, commands 10 -> 58,
`hanzo --version` 0.1.0 -> 0.4.4, all four endpoints canonical. hanzo-iam
19/19 pass; hanzo-cli's 20 failures are unchanged before and after and are all
live-service auth (no stored token in this environment).
Co-authored-by: Hanzo Dev <[email protected]>
Closes the last gap in the one-way Hanzo control surface. IAM/KMS/PaaS
already had both CLI subcommands and MCP tools; S3 had neither.
- hanzo s3: buckets/mb/rb/ls/stat/rm/presign over hanzo_s3 (MinIO) client,
creds from env (inject from KMS, never plaintext). Registered in the
unified hanzo CLI alongside iam/kms/paas.
- hanzo-tools-s3: S3Tool MCP tool (same action-dispatch pattern as PaaSTool),
exported via the hanzo.tools entry point; s3 added to loader prefix map.
- uv workspace: map hanzo-cli/iam/kms/s3 + tools-s3 to local sources so the
unified CLI resolves on-disk packages (fixes hanzo_iam ImportError from a
stale published 1.29.0 wheel shadowing local 1.30.0).
Tests: 7 CLI + 14 MCP, all green.
Bumps hanzo-iam from 1.29.0 (older Casdoor SDK port) to 1.30.0 with a
purpose-built IAM SDK aligned to the canonical IAM_ env contract.
- ENV_PREFIX="IAM_" only — no HANZO_IAM_ / {ORG}_IAM_ fallback chain.
- IAMConfig.from_env reads IAM_ENDPOINT, IAM_CLIENT_ID, IAM_CLIENT_SECRET,
IAM_ORG, IAM_APP, IAM_CERT, IAM_USERINFO_URL.
- New FastAPI middleware module wraps Casdoor sign-in flow with
request-state user injection.
- 19 unit tests covering env-read, validation, and FastAPI integration.
Consumer packages (hanzo-cli, hanzo-tools-auth, hanzo-tools-paas) bump
their hanzo-iam dep to >=1.30.0.
Tag: hanzo-iam-1.30.0
Add TOML config parser that converts hanzo.toml manifests into PaaS
container API payloads. New `deploy up` command reads hanzo.toml from
CWD and creates or updates containers. Also adds --config flag to
`deploy create` for explicit manifest path. Adds tomli dependency for
Python 3.9/3.10 compat.
Co-authored-by: Hanzo Dev <[email protected]>
Every service command (vector, kv, search, doc, events, pubsub, queues,
jobs, secrets, tasks, fn, auto, flow, ml, o11y, cx, growth, platform)
now makes authenticated HTTP calls via shared service_request/check_response
utilities in base.py. No stubs, no hardcoded data, no placeholders.
Bump hanzo 0.4.0→0.4.1, hanzo-cli 0.2.0→0.2.1.
- Merged hanzo-cli into main hanzo package (v0.2.4)
- Removed hanzo-mcp-client (using official MCP client)
- Removed empty packages (hanzo-a2a, hanzo-cluster, hanzo-miner, hanzo-tools)
- Added hanzo and hanzo-repl to CI pipeline
- Updated all packages with parallel testing (pytest-xdist)
- Consolidated from 15 to 8 active packages
- Fixed imports and dependencies after consolidation
- All CI tests passing with 111 total tests across 5 packages
zeekayandHanzo Dev