CLI reference

Every terminalhire subcommand, grouped by what it's for. th works as a short alias everywhere you see terminalhire. terminalhire --help prints a shorter list in the terminal; this page is the full one.

Account — profile and sync are covered in Privacy

Matching — see Getting started

Credential — see Proof of Work

Postings — see Postings and claims

terminalhire claim <token> with no verb records the claim that token names — that is what a th:// link runs.

claim start takes --here to use the directory you are in, --fork / --assign / --no-assign to choose what happens on the GitHub side, and --intent "…" / --eta "…" to say what you are doing and by when. claim submit takes --yes, --title <t>, --body-file <path> / --no-body, --no-closes, and, on a first-party posting, --screenshots <file>: a JSON list of up to six PNGs with captions, shown to the poster beside the verification run's own pictures (see Verifying your work).

claim start and claim slice both take --dir <path>, which names where the workspace lands, and --open <agent>, which hands that directory to claude, codex, agy or cursor-agent once it is ready. A directory that already holds files is never written into: the delivery goes to a numbered sibling and prints where it went.

Both commands finish by leaving you in the workspace — your own shell, started there, with exit bringing you back where you were. --open <agent> starts that agent instead. --stay prints the cd and returns, which is also what you get with no terminal attached, so scripts and --watch are unaffected.

Verification — see Verifying your work

Defaults come from .th-run.json in the checkout, so a claim you run repeatedly needs no flags. Needs Docker running.

Read the exit code. 0 the tests were green. 1 we judged the work and it is not green. 2 we rendered no verdict — our environment could not run it honestly, so nothing was said about your work. See how verification runs work.

Connect — see Connect

Craft knowledge — your own notes on a repo

Posting from the terminal — see Post a paid task

Audits — for TerminalHire reviewers

These work only for TerminalHire reviewers on the allowlist; the server refuses everyone else. They use the session from terminalhire link. Add --json to any of them for JSON on stdout.

Exit codes: 0 done; 1 a usage or network failure, a server error, or HTTP 408 or 429 (try again); 2 the server refused, including an expired session (run terminalhire link).

Surfaces — see Claude Code surfaces

Spinner tips lead with claimable first-party paid tasks when available. Otherwise they favor roughly ten contribution opportunities per role; relevant public paid tasks follow the role.

Pointing the CLI somewhere other than terminalhire.com

Every command talks to https://terminalhire.com unless you say otherwise. If you are working against the dev deployment, or against a copy of the web app running on your own machine, a bare command asks production instead — and production answers about a claim it has never heard of, which reads as "this work does not exist".

For the dev deployment, use thdev instead — it is the same CLI with that origin pinned, so it needs no variable at all and works the same in PowerShell, cmd.exe and bash. VAR=value command is a POSIX-shell one-command assignment: on Windows it does not set anything, and the command silently reaches production.

# the dev deployment — every command, no variable
thdev claim slice <id>
thdev bounties
thdev login

# a web app running on your own machine, on whatever port it serves
TERMINALHIRE_ALLOW_LOCAL_API=1 TERMINALHIRE_API_URL=http://localhost:3000 \
  terminalhire claim slice <id>

The dev deployment has its own credential store, ~/.terminalhire-dev, and every way of pointing at dev uses it: thdev, the variable, an MCP server entry that sets the variable. So thdev login and terminalhire login are separate accounts on disk, neither overwrites the other, and a sign-in through one spelling is visible to the others. Set TERMINALHIRE_DIR to choose a store yourself; it wins over that default. Loopback keeps ~/.terminalhire and still uses the variables above: there is no pinned binary for an arbitrary local port.

Any other host is refused outright rather than quietly falling back to production — writing a claim to the wrong environment is not something a later command can undo. The two loopback flags are separate because they grant different things: the first lets stored credentials reach a local listener, the second lets a browser sign-in happen there, and neither is implied by the other.

Your session belongs to one deployment. Signing in on production does not sign you in on dev, so point login at the same place before anything that says a claim is not registered to you:

thdev login

The claim page prints the right form into its own copy buttons — thdev … on dev, a prefixed command on loopback — so a command copied from a page is already pointed at the deployment that served it.

Not opening a browser

login, sync --push and the claim sign-in steps print the address, then try to open it in your browser. Set TERMINALHIRE_NO_BROWSER=1 to skip that on a headless machine and open the printed address yourself.