Skip to content

Global Flags and configuration

View as Markdown

Use this page before deeper command reference pages when you need the shared rules that apply across the CLI.

The root thru parser defines these flags globally, so they apply to every command family:

FlagWhat it doesDefined in
--jsonEmit machine-readable output instead of the default text output.Cli.json
--quietSuppress non-essential output, including interactive version check notifications.Cli.quiet
--url <URL>Override the RPC base URL for this one invocation.Cli.url
--network <NAME>Use a named network profile from config for this one invocation.Cli.network
Terminal window
thru auth login # Approve in your browser
thru auth login --no-browser # Print the approval URL/code
thru auth status # Check the saved account
thru auth logout # Revoke this installation and clear credentials

Login is independent of wallet keys and networks. Each machine has its own session. Re-login replaces that machine’s session after approval; failed authorization preserves it.

Environment variablePurpose
THRU_DEVELOPERS_URLDevelopers origin; defaults to https://dev.thru.org. Local example: http://127.0.0.1:3018.
THRU_DEVELOPERS_CREDENTIAL_STOREkeyring (default), or explicitly file on Unix.
THRU_DEVELOPERS_API_KEYRaw key from Developers Account settings; overrides login only for faucet withdraw thrusd and faucet withdraw thru.

Credentials are isolated by origin and stored in macOS Keychain, Windows Credential Manager, or Linux Secret Service. File storage uses ~/.thru/cli/auth, with directory mode 0700 and file mode 0600. Log out before switching stores, then log in again. macOS may prompt again after a debug rebuild.

Keep API keys in your secret environment, never URLs or committed files. API keys do not affect auth status or auth logout. Developers requests require HTTPS except on loopback; --insecure does not change this.

The CLI loads and saves its config at:

~/.thru/cli/config.yaml

That config stores:

  • the default RPC base URL
  • saved keys
  • program IDs for built-in programs
  • named network profiles
  • the default named network
  • dev toolchain and SDK install metadata

When a command needs an RPC target, the CLI resolves it in this order:

  1. --url
  2. --network
  3. the configured default_network
  4. the base rpc_base_url already stored in config

Use --url when you want a one-off override. Use --network when you want to target a saved profile without changing the default.

For agent workflows, prefer --json whenever you expect to parse a result or branch on output.

Use text output when:

  • you are reading an error interactively
  • the command is primarily instructional
  • the command prints human-oriented follow-up guidance

Identifier handling is not uniform across the CLI.

Some commands accept:

  • key names from config such as default or treasury
  • raw Thru public addresses in ta... format
  • 32-byte hex public keys

Other commands require raw public keys or addresses and do not resolve key names for all arguments.

Practical rule:

  • if the page says “key name from config,” a config alias is valid
  • if the page says “public key” or “Thru address,” prefer a raw ta... address or hex pubkey
  • if a command takes --fee-payer, that flag usually resolves through configured key names

The default key is a fallback, not a global configuration requirement. Commands with an explicit named signer remain usable when no default key is configured; a command errors only when it actually needs the omitted default.

Several command families default to program IDs stored in config unless you override them with flags.

Common examples:

  • program and abi use configured manager program IDs
  • token reads the token program from the mint or token account the command names, falls back to the configured token program ID, and supports --token-program to override both. See Token Program Selection
  • registrar and nameservice use configured name service and registrar program IDs
  • wthru supports both --program and --token-program
  • Load this page once, then move to a family page instead of repeating config rules in context.
  • Prefer --json for automation or follow-up tool use.
  • If a command can mutate config, state, or on-chain accounts, the family page should be treated as the source of truth for accepted identifiers and side effects.