# 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.

```text
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.