atproto git client
atgc docs environment.md
3.7 kB

Environment #

Twenty-two ATGC_* variables steer atgc at runtime, and every one of them is listed here; the handful it reads that are not its own are named below. atgc <command> --help names the ones that pair with a flag; these are the whole set.

ATGC_ACCOUNT           which logged-in account to act as (--account outranks it)
ATGC_NO_INPUT          nobody is watching: never wait, never open a browser
ATGC_DEBUG             print HTTP traffic and full error bodies
ATGC_LOG               per-topic output filter, e.g. note,pds=debug
ATGC_CONNECT_TIMEOUT   seconds to spend getting connected (default 5)
ATGC_READ_TIMEOUT      seconds a connected request may stall for (default 30)

ATGC_PLC               the PLC directory        (default https://plc.directory)
ATGC_BOBBIN            Tangled's index          (default https://api.tangled.org)
ATGC_APPVIEW           Tangled's web appview    (default https://tangled.org)
ATGC_KNOT              every knot, whatever a repo record names it
ATGC_BSKY_APPVIEW      Bluesky's appview        (default https://public.api.bsky.app)

ATGC_OAUTH_LOG         where oauth.jsonl goes, or `off`
ATGC_PDS_LOG           where pds.jsonl goes, or `off`
ATGC_GIT_LOG           where git.jsonl goes, or `off`

ATGC_USE_BOBBIN        read listings from the index as well as your PDS
ATGC_USE_WEB           read listings from tangled.org's own API as well
ATGC_REPORT_SPACE      file `atgc report <kind>` onto a different board
ATGC_REPORT_REPO       file `atgc report bug` against a different repo

Each endpoint variable replaces a whole base URL, so a local instance on a port works: ATGC_APPVIEW=http://127.0.0.1:3000. They are the reason atgc can be pointed at a test deployment, and they are deliberately environment-only — a checked-in file that silently redirected somebody's PDS traffic would be a different object with a different threat model.

The switches — ATGC_NO_INPUT, ATGC_DEBUG, ATGC_USE_BOBBIN, ATGC_USE_WEB, and the off on each log path — are all read the same way. Unset, empty, 0, false, no and off are off, in any case; anything else is on. So ATGC_NO_INPUT=false means interactive, which is the only thing that spelling can mean. CI and CLAUDECODE are read the same way, and NO_COLOR is not: its own spec says any non-empty value disables color, NO_COLOR=false included.

Those two are not atgc's and are read anyway, because what they say is true whoever set them. CI means a job with no browser in reach, so auth login refuses there rather than waiting five minutes for a consent nobody can give. CLAUDECODE means an agent is running this, and it decides which of an account's logins this process uses.

That last one is worth being precise about, because an account can hold two — a person's and an agent's, so that either can be given up without the other. CLAUDECODE is read on every command, to answer "which of them am I", and written down once at auth login, to record which one that login made. Both halves are needed and they fail in the same direction: a process whose value disagrees with the login that made its grant is refused, never quietly handed the other one. An agent whose harness sets it at login and not afterwards therefore meets a refusal, which is a repair away — atgc auth login from where it is actually running — and not a credential it should not have had.

Four more, ATGC_BUILD_COMMIT, ATGC_BUILD_TARGET, ATGC_BUILD_PROFILE and ATGC_BUILD_RUSTC, are read by build.rs while the binary is being compiled and are never consulted at runtime. atgc about prints what they recorded.