mirror of
https://github.com/hanzoai/dev.git
synced 2026-10-25 03:32:32 +00:00
zeekayandHanzo Dev
d3d1dfa1d3
hanzoai/dev went public defaulting to someone else's cloud. Four things were
wrong, and all four now have a test that fails if they come back.
DEFAULT PROVIDER AND MODEL. built_in_model_providers() gains `hanzo` -- the
Hanzo Cloud at api.hanzo.ai/v1, Responses wire, bearer from HANZO_USER_KEY --
and it is the default. The default model is zen5-coder. This was not cosmetic:
the old default is not in the gateway catalog, so it 400s against our own
cloud. Measured, not assumed:
POST api.hanzo.ai/v1/responses model=gpt-5-codex -> 400 "model is not
available. Use GET /v1/models to list available models"
POST api.hanzo.ai/v1/responses model=zen5-coder -> 200, clean output
Our own CLI already documented the bug from the other side -- dev.rs says
"Name the model too -- codex's built-in default is not in the gateway catalog
and would 400" and passes `-c model=` on every launch to work around it. It
also asserts that on the native gateway NO model_provider override is needed,
which is only true once `hanzo` is the built-in default. It is now.
zen5-coder over enso because dev is a coding agent and because enso returns
system-prompt text on the Responses wire that dev actually speaks; zen5-coder
returns the answer. Model ids were read from GET /v1/models with a bearer, not
guessed. Other providers stay fully configurable -- this is the default, not
the only choice.
THE LOGIN COMMAND. Messages said `code login` / `codex login`. The real command
is `hanzo auth login` (`hanzo login` is not a command -- it is swallowed as an
AI task). It now lives once, as auth::LOGIN_COMMAND, so no message can drift
into naming a command that does not exist. References to this binary's own
subcommand became `dev login`.
A BINARY NAMED dev. HEAD built `code` and `codex` and nothing named `dev`, so a
release cut today would ship no `dev` -- and `hanzo code` launches a bare `dev`
off PATH, so every new install would break. `dev` is now the canonical bin,
declared first; `code` remains as an alias to the same program, never the
reverse. The CLI identifies as `dev` / "Hanzo Dev", not "OpenAI Codex".
OUR NAMESPACES. The pipeline published to @just-every/* on npm and pushed
formulae to just-every/homebrew-tap. Both of ours already exist and are already
populated at v0.6.91 -- @hanzo/dev plus all five @hanzo/dev-<target> packages,
and hanzoai/homebrew-tap's Formula/hanzo-dev.rb, which installs `dev` and
expects assets named dev-<triple>. Nothing here is squatted; this is our own
distribution, reclaimed. Assets are renamed to match the formula.
Two live supply-chain bugs fell out of that, both worse than a naming problem:
postinstall.js (runs on every npm install) and the tui auto-updater fetched
from a third party's releases -- the updater also told our users to
`npm install -g @just-every/code@latest`. Worse, a shadowed `isWSL` const put
the two fast paths in the temporal dead zone, so their catch blocks swallowed
the error and EVERY install fell through to that download: the five published
platform packages were never used, and the third-party fetch was not an edge
case but the only path that ran. Fixed and exercised in a sandbox across all
three paths. codex-cli/.pack/ -- a committed `npm pack` artifact CI
regenerates, and the reason the bad URL had two homes -- is now untracked.
DURABILITY, because upstream-merge.yml merges openai/codex every 30 minutes.
A one-time edit to a default is a suggestion that survives until the next
merge. Two mechanisms:
- .github/merge-policy.json prefer_ours_globs listed only codex-rs/** while
the workspace that SHIPS is code-rs/**, so it protected nothing that
ships. The identity-bearing code-rs files are now listed.
- code-rs/core/tests/hanzo_identity.rs asserts all four properties -- the
provider, a Zen default, a bin named dev, and no third-party publish
target. Upstream has no such file, so a merge cannot conflict with it or
carry the guard away with the thing it guards. Policy can be edited;
a red build cannot be ignored.
The gate is not decorative: it failed on the un-retargeted pipeline
("release.yml still references `@just-every/`") and went green only when the
pipeline was actually fixed.
Verified: cargo build --bin dev clean; hanzo_identity 4/4; code-core lib
332 passed, 1 failed -- git_info::test_collect_git_info_with_remote, which
fails identically on a clean origin/main checkout here because this machine
has a global [email protected]:.insteadof rewrite. Pre-existing and
environmental, not from this change.
$ dev exec "say OK" # fresh profile, no config
Hanzo Dev v0.0.0
model: zen5-coder
provider: hanzo
Co-authored-by: Hanzo Dev <[email protected]>
88 lines
2.6 KiB
Bash
Executable File
88 lines
2.6 KiB
Bash
Executable File
#!/usr/bin/env bash
|
||
|
||
# Install native runtime dependencies for codex-cli.
|
||
#
|
||
# Usage
|
||
# install_native_deps.sh [--workflow-url URL] [CODEX_CLI_ROOT]
|
||
#
|
||
# The optional RELEASE_ROOT is the path that contains package.json. Omitting
|
||
# it installs the binaries into the repository's own bin/ folder to support
|
||
# local development.
|
||
|
||
set -euo pipefail
|
||
|
||
# ------------------
|
||
# Parse arguments
|
||
# ------------------
|
||
|
||
CODEX_CLI_ROOT=""
|
||
|
||
# Until we start publishing stable GitHub releases, we have to grab the binaries
|
||
# from the GitHub Action that created them. Update the URL below to point to the
|
||
# appropriate workflow run:
|
||
WORKFLOW_URL="" # Optional override; if empty, caller must pass --workflow-url
|
||
|
||
while [[ $# -gt 0 ]]; do
|
||
case "$1" in
|
||
--workflow-url)
|
||
shift || { echo "--workflow-url requires an argument"; exit 1; }
|
||
if [ -n "$1" ]; then
|
||
WORKFLOW_URL="$1"
|
||
fi
|
||
;;
|
||
*)
|
||
if [[ -z "$CODEX_CLI_ROOT" ]]; then
|
||
CODEX_CLI_ROOT="$1"
|
||
else
|
||
echo "Unexpected argument: $1" >&2
|
||
exit 1
|
||
fi
|
||
;;
|
||
esac
|
||
shift
|
||
done
|
||
|
||
# ----------------------------------------------------------------------------
|
||
# Determine where the binaries should be installed.
|
||
# ----------------------------------------------------------------------------
|
||
|
||
if [ -n "$CODEX_CLI_ROOT" ]; then
|
||
# The caller supplied a release root directory.
|
||
BIN_DIR="$CODEX_CLI_ROOT/bin"
|
||
else
|
||
# No argument; fall back to the repo’s own bin directory.
|
||
# Resolve the path of this script, then walk up to the repo root.
|
||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||
CODEX_CLI_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
|
||
BIN_DIR="$CODEX_CLI_ROOT/bin"
|
||
fi
|
||
|
||
# Make sure the destination directory exists.
|
||
mkdir -p "$BIN_DIR"
|
||
|
||
# ----------------------------------------------------------------------------
|
||
# Download and decompress the artifacts from the GitHub Actions workflow.
|
||
# ----------------------------------------------------------------------------
|
||
|
||
WORKFLOW_ID="${WORKFLOW_URL##*/}"
|
||
|
||
ARTIFACTS_DIR="$(mktemp -d)"
|
||
trap 'rm -rf "$ARTIFACTS_DIR"' EXIT
|
||
|
||
# NB: The GitHub CLI `gh` must be installed and authenticated.
|
||
gh run download --dir "$ARTIFACTS_DIR" --repo hanzoai/dev "$WORKFLOW_ID"
|
||
|
||
# Each build job uploads its artifact as `binaries-<target>` containing
|
||
# `dev-<target>[.exe].zst`.
|
||
for target in \
|
||
x86_64-unknown-linux-musl \
|
||
aarch64-unknown-linux-musl \
|
||
x86_64-apple-darwin \
|
||
aarch64-apple-darwin \
|
||
x86_64-pc-windows-msvc.exe
|
||
do
|
||
zstd -d "$ARTIFACTS_DIR/binaries-${target%.exe}/dev-$target.zst" -o "$BIN_DIR/dev-$target"
|
||
done
|
||
|
||
echo "Installed native dependencies into $BIN_DIR"
|