graphban-cli
gban — the client for a human at a terminal.
Five surfaces existed before this and none of them was for a person at a shell prompt:
graphban talks to the database from inside the container, gbfleet supervises processes,
gbagent is a spawned child, the web app is a browser, and /api/mcp is for agents. Issuing
a seat, seeing why an agent is stuck, or re-tasking one meant opening a browser.
Specified by PRD-40.
Install
uv tool install graphban-cli
or, on macOS:
brew install asc-me/tap/gban
The formula carries no resource stanzas — graphban-cli has no runtime dependencies, so
there is nothing to vendor and nothing to regenerate when a transitive moves. The supervisor
is deliberately not in the tap; see below.
Add the supervisor too if you run waves — a separate package, and gban fleet hands off to
it. At a terminal, gban fleet will offer to run this for you when it finds no supervisor;
it asks first and never installs on a bare return, because a person who typed a read-only
command did not consent to software being installed:
uv tool install graphban-fleet
That also gives you gbagent, the first-party coding agent: it is an entry point of
graphban-fleet, not a package of its own, because the supervisor resolves it on PATH like
any other vendor binary.
uv tool update-shell once, if uv says the bin directory is not on your PATH.
uv tool upgrade --all to move both forward.
Two commands rather than one, and an extra (graphban-cli[fleet]) is deliberately not
offered: uv tool install exposes only the REQUESTED package's executables, so an extra
installs gbfleet into gban's environment and puts it on no path at all. Measured — with
the extra, gban fleet reported "gbfleet is not installed here" while gbfleet sat in the
very environment it was running from.
gban pulls nothing: client.py is urllib.request throughout, and the install lands
exactly one distribution. gbfleet brings httpx and its transitives, which is why they are
separate packages and not one.
With pip instead, into an environment you already have:
pip install graphban-cli
gban looks for gbfleet beside its own interpreter before falling back to PATH, so that
shape works with neither on PATH.
To run an unreleased change, install from the repository instead — the same spec the release builds from:
uv tool install "git+https://github.com/asc-me/graphban.git#subdirectory=cli"
Releasing is docs/releasing.md.
gban login --server https://cloud.agentldgr.dev
gban doctor # both halves: the ledger, and the local fleet
gban agents # the roster, and why an agent is stuck
gban agents role SA-A4 planner # what used to need a browser
gban seats issue worker worker planner # one entry per agent
gban keys # which key is that agent on
gban fleet up --seats-file seats.txt --adapter claude # hands off to gbfleet
seats issue takes one role per agent, repeats included, because that is the server's
own shape: two agents on one seat share a session and cannot review each other. Each code is
printed once and written nowhere — a CLI that helpfully saved them would invent a second
credential at rest that no route and no test knows about.
agents prints what an agent was last refused, and why. That line is the reason the verb
exists: a roster saying "idle worker" for an agent being told no on every call it makes is
what made the Super-Arc diagnosis take a database query.
agents role re-tasks a live agent within its credential's ceiling and never past it. A
role the key does not permit is the server's refusal, printed in the server's own words;
widening a ceiling means minting a different credential, and keeping those two acts apart is
the point of having a ceiling. It lands on the agent's next poll.
Enabling delegation on a project
gban login # once, at a terminal
gban setup # everything mechanical between that and a delegating agent
gban setup --auto # …or every project whose repository sits here or beside here
An agent with the delegation skill runs all of this for you except gban login, which it
hands back as a ! gban login line to type — it needs a terminal, and no agent has one — and
then carries on from where you left it.
The directory names the project. Run setup from inside the repository the work belongs
to and it matches that directory against the projects you can read. An explicit --project
wins; nothing else does. In particular the default gban login stores is not used here and
is named in the refusal when it exists — logging in once inside one project must not quietly
mint a credential for it while you are standing in another repository, and a key in the wrong
project is not a mistake anybody notices quickly.
setup mints a project-scoped credential, writes the graphban and gbfleet MCP entries
into every parent harness that would actually read them, installs the supervisor if it is
missing, drops the delegation skill into .claude/skills/, and then verifies rather than
asserting: it asks the new credential what it can actually see. Restart the session that will
call delegate/spawn afterwards — MCP servers are read at startup.
Three properties worth knowing, each of which is a bug this command exists to not have:
- The credential does not expire.
gban keys mintproduces a wave key, which lasts a day (FLEET_KEY_DAYS); that is right for a wave and wrong for a project. Only seats expire. - It writes where the harness will actually read. There is more than one. Claude Code
reads
~/.claude.json's per-projectmcpServers(JSON), which outranks a repository.mcp.json— writing the repository file under a stale entry leaves the agent on the old key, and surfaces as a JSON parse error because the harness is parsing a 401 body. Grok reads~/.grok/config.toml'smcp_servers(TOML, snake_case;mcpServersparses and loads nothing). Writing only Claude's file while Grok holds a different key reports success and leavesdelegateunadvertised (GRPH-825). Grok'sgbfleetMCP also gets--workspace ~/.grok/gbfleet-wt/<repo>: the sibling default is a path Grok's sandbox cannot write, and spawn then dies asgit worktree add128 (GRPH-826). Claude keeps the sibling default.--scope useris the default because a credential outside the repository cannot be committed. Re-running a working setup still repairs a missinggbfleetentry and a missing--workspace; reuse skips a mint, never a write. --automatches, and says so. A project carries no repository link — no remote, no path — so--autocompares your project ids and names against this directory, what is in it, and its siblings. One level, never a recursive walk. Two directories answering to one project, or one directory answering to two, are refused rather than guessed: a credential minted into the wrong repository is not a mistake anybody notices quickly.- It refuses to write a key into a file git tracks.
--scope projecton a tracked.mcp.jsonor.grok/config.tomlis refused rather than warned about, because a warning attached to committing a credential still commits it.
Wiring a checkout to Swamp
gban swamp setup
Steps 3 and 5 of the Swamp runbook:
repo init, extension source add, vault create, and the gate credential — minted,
piped to swamp vault put on stdin, then checked for the scopes it actually came back with.
Every step is skipped when already done.
Two things it will not do. It does not install Swamp, because that install pipes a remote
script into a shell. And it never writes the gate key into an MCP config: gban setup's agent
key must not carry gate, or the agent doing the work attests its own completion — which
fails silently, since a gate that always says yes looks exactly like a gate that held.
gban login wants a real terminal
It refuses without one, rather than prompting. getpass falls back to a plain echoing
read when it cannot turn echo off — it warns, but the warning arrives after the person has
decided to type — so a login through a pipe, a heredoc or an editor's command runner would
put the password in the scrollback. There is no non-interactive login yet (PRD-40 open
question 2: an API key cannot reach the JWT routes, so CI would need a service session).
Why not gb
Because gb is already git branch on a large share of developer machines, and an alias
beats a binary on PATH. The deployed walk hit it on the very first command and got git's
usage text; nothing inside the process can detect that, because by the time gb would have
run, the alias did not.
It is not one alias but a whole namespace. oh-my-zsh's git plugin — which is where most of
these come from — defines sixteen gb* aliases and ten grb*, so gb, gba, grb and
gbl are all spoken for. gban is outside it, still short, and still says which product it
belongs to.
Licence — Apache-2.0, deliberately not the repository's FSL-1.1
The repository is FSL-1.1-Apache-2.0. This directory is
Apache-2.0, for the reasons PRD-22 §8 gives for fleet/ — every one of which
applies here identically. gban is inert without a Graphban server and holds no authority of
its own, so FSL's Competing Use clause protects the server and protects nothing here. It is a
laptop-installed developer CLI, which is exactly the kind of dependency that has to clear a
corporate licence policy scanner.
Why it is in this repository
Not a second repository, for the reason fleet/README.md gives for
the supervisor, with more force: the client↔server contract has no schema anywhere, and a
cross-repo break would present as absence reading clean — gban still runs, nothing errors, the
verb quietly stops meaning what it said. The evidence is recent and specific: ROLES lost
reviewer in one PR while another added a test naming it, and CI caught the pair inside
seventeen minutes because both lived in one repository. Split across two, that lands as a bug
report from somebody whose gban agents role ... reviewer started refusing.
Not inside backend/, because graphban-api pulls fastapi, sqlalchemy, pgvector, psycopg,
alembic, redis and cryptography, and this installs on a laptop. tests/test_packaging.py
derives its forbidden set from the backend's own dependency list rather than a denylist
somebody maintains.
What it is not
It is not a second web app: no board, no PRD editor, no search. Every verb is either something a human currently opens a browser for, or a diagnosis nothing else gives.
It is not graphban, which talks to the local database from inside the container and
stays exactly as it is. Mixing "against the DB in the container" and "over HTTP from a laptop"
into one command is an ambiguity that ends with somebody purging the wrong instance.
It holds no state the server does not and computes nothing the server computes. Every verb is one endpoint, called once (PRD-40 D11); an ordering between two calls would be a rule, and a rule in the client is a second definition of something the server already enforces.
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file graphban_cli-0.4.0.tar.gz.
File metadata
- Download URL: graphban_cli-0.4.0.tar.gz
- Upload date:
- Size: 75.1 kB
- Tags: Source
- Uploaded using Trusted Publishing? Yes
- Uploaded via:
twine/7.0.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
ca33379908a81e644ba2cc410d03a6615816fac3d2a0a1118344cc845aee3107
|
|
| MD5 |
2515c2a9e07eb883743ebd1fa14b4453
|
|
| BLAKE2b-256 |
3d0b0c54326a91ab687262be578a304df66202a377959fb8b2a5732bf8784b9b
|
Provenance
The following attestation bundles were made for graphban_cli-0.4.0.tar.gz:
Publisher:
release-cli.yml on asc-me/graphban
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
graphban_cli-0.4.0.tar.gz -
Subject digest:
ca33379908a81e644ba2cc410d03a6615816fac3d2a0a1118344cc845aee3107 - Sigstore transparency entry: 2784948176
- Sigstore integration time:
-
Permalink:
asc-me/graphban@32479242be1a64f1ec08b92b49e093a04f286fce -
Branch / Tag:
refs/tags/cli-v0.4.0 - Owner: https://github.com/asc-me
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
release-cli.yml@32479242be1a64f1ec08b92b49e093a04f286fce -
Trigger Event:
push
-
Statement type:
File details
Details for the file graphban_cli-0.4.0-py3-none-any.whl.
File metadata
- Download URL: graphban_cli-0.4.0-py3-none-any.whl
- Upload date:
- Size: 50.2 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? Yes
- Uploaded via:
twine/7.0.0 CPython/3.13.14
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
b66513a0308313f0d2dd7416b2927861f31a3c0884c6a46f9b43b32cd2e06cc9
|
|
| MD5 |
de420bab283e31d80efd8de04fc1d79c
|
|
| BLAKE2b-256 |
123397fc0cacc396998ace90e425191638fe46c5699c9edc43551670b89dc0bf
|
Provenance
The following attestation bundles were made for graphban_cli-0.4.0-py3-none-any.whl:
Publisher:
release-cli.yml on asc-me/graphban
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
graphban_cli-0.4.0-py3-none-any.whl -
Subject digest:
b66513a0308313f0d2dd7416b2927861f31a3c0884c6a46f9b43b32cd2e06cc9 - Sigstore transparency entry: 2784948247
- Sigstore integration time:
-
Permalink:
asc-me/graphban@32479242be1a64f1ec08b92b49e093a04f286fce -
Branch / Tag:
refs/tags/cli-v0.4.0 - Owner: https://github.com/asc-me
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
release-cli.yml@32479242be1a64f1ec08b92b49e093a04f286fce -
Trigger Event:
push
-
Statement type: