493f33d9 · zzmq.dev@gmail.com/zz
Commit
493f33d9657058ec070c8dbc04c1249029f03c7a
Simplify the CLI identity story: --as <name>, a positional repo, and ZZ_ID Per direct request: using zz work/review/repo submit as a managed agent required hand-building a separate ~/.zz/credentials.json-shaped file and pointing ZZ_CREDENTIALS at it every time -- real friction for the exact everyday case (you're logged in as yourself, you just want to run something as an agent you created). New resolution order (lib/identity.ts's resolveIdentity, shared by work/review/repo submit): 1. ZZ_ID="<username>:<token>" -- headless/automated contexts with no `zz login` session at all. 2. ZZ_ID_FILE=<path to a file with that same text> -- same thing, out of an env var (visible in `ps`/shell history/CI logs) and into a file instead. 3. --as <name>: your own `zz login` session resolves who YOU are; <name> expands to "<your username>[<name>]" (unless already fully-qualified) and its token comes from a local registry (~/.zz/agents.json) that `zz agent create`/`zz agent token` now populate automatically -- no manual file-building at all for the common case of acting as an agent you created from this machine. 4. No --as: your own `zz login` session, directly (unchanged default). This is explicitly NOT server-side impersonation -- your own token never acts as another agent. --as only ever sends that agent's own real token, which has to already exist locally (or via ZZ_ID) for it to work. The anti-impersonation check in webApp.ts is untouched. `zz work [repo]` and `zz review [repo]` also take the slug as a plain positional argument now (shorthand for --repos <repo>), instead of requiring `--repos owner/repo` for the single-repo case. api.ts gained a small `setActiveToken`, set once near the top of each of these three commands right after resolving identity -- every downstream apiFetch call (via callRemoteTool, the remote Backend, git clone auth) picks it up without threading a token through every function signature in between (agent/loop.ts and agent/scriptedWork.ts are untouched). A per-call token still wins if one is ever passed explicitly. Updated the web app's token-reveal page (webApp.ts) to match: shows `ZZ_ID="<username>:<token>"` instead of a JSON credentials-file blob, and notes that `zz work --as <name>` already picks up a token created from the same machine's login session with no extra steps.
Troy Howard <thoward37@gmail.com> -- 2026-10-12T13:53:31.000Z