Skip to main content
Environment variables can control Claude Code behavior such as model selection, authentication, request routing, and feature toggles. Many of the same behaviors can also be configured through a settings file field, a CLI flag, or an in-session command like /model. This page covers how to:

Set environment variables

A variable you set in your shell lasts for that terminal session, while a variable in a settings file applies every time claude runs.

In your shell

Set the variable before launching claude:
To set it for every session, add the export line to ~/.bashrc, ~/.zshrc, or your shell’s profile file.
The assignment line prints nothing on success. To confirm the variable is set, print it in the same shell:

In settings files

Add variables under the env key in a settings.json file, creating the file if it doesn’t exist. Claude Code reads them directly from the file, so they take effect no matter how claude was launched. A running session applies new and changed values to its environment when you save the file, but a feature that reads its variables once at startup, such as OpenTelemetry monitoring, keeps its startup values until you relaunch. Removing a variable from the file doesn’t unset it in a running session; the removal takes effect the next time you launch claude.
~/.claude/settings.json
The file you choose controls who the variables apply to: See Settings files for where each file lives and Settings precedence for how they combine when more than one sets the same variable.

Precedence

Some behaviors have both an environment variable and a dedicated settings key, and which one Claude Code reads first differs per key. For ANTHROPIC_MODEL and CLAUDE_CODE_AUTO_CONNECT_IDE, Claude Code reads the variable first and uses the model or autoConnectIde setting only when the variable is unset. For the pair you’re setting, check the variable’s row below and the key’s entry on the settings reference. When the same variable is set in both your shell and a settings file env block, the settings file value applies in most sessions. Claude Code writes each env entry into the process environment, replacing the value inherited from the shell. How env values interact with your shell covers the sessions that keep the inherited value instead, and the env setting says when it applies them. A few variables are special-cased; the env setting lists the exceptions. In a settings file you can set a variable but you can’t remove one. To override a variable you can’t unset, such as a stale CLAUDE_CODE_USE_VERTEX exported by a shell profile you don’t control, set it to an empty string in the env block: "CLAUDE_CODE_USE_VERTEX": "". Claude Code treats the empty value as unset for provider selection. Subprocesses still inherit the empty value. Between settings files, env values follow settings precedence, so a managed settings entry overrides the same variable in user or project settings. Project and local settings can’t set some variables, such as CLAUDE_CONFIG_DIR and the OpenTelemetry exporter variables. Variables Claude Code ignores in env lists them, along with the OpenTelemetry off values that still apply. How an environment variable interacts with CLI flags and in-session commands varies per feature: --model and /model override ANTHROPIC_MODEL, while CLAUDE_CODE_EFFORT_LEVEL overrides --effort and /effort. When a variable interacts with another configuration source, its row in the Variables list states the precedence or links to the page that documents it. Claude Code reads shell environment variables at startup, so changes to them take effect the next time you launch claude. Variables set under the env key in settings files are reapplied to a running session when the file changes, with the startup-only exception described in In settings files.

Variables

Numeric variables such as timeouts, token budgets, and retry counts accept scientific notation and digit-separator spellings in addition to plain digits, except where a variable’s row notes it takes plain digits only. For example, Claude Code reads 2e3 as 2000 and 64_000 as 64000. Before v2.1.211, these spellings could silently set a much smaller value, such as 1e6 setting a timeout to 1.
For variables that turn a behavior on or off, set 1, true, yes, or on to turn it on and 0, false, no, or off to turn it off, in any casing.Some variables read only whether you set them at all, so any non-empty value including 0 turns the behavior on, and you turn the behavior off by unsetting the variable or setting it to an empty value. These variables work that way:
  • CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC
  • DISABLE_TELEMETRY
  • DISABLE_ERROR_REPORTING
  • CLAUDE_CODE_TMUX_TRUECOLOR
  • FALLBACK_FOR_ALL_PRIMARY_MODELS
  • IS_DEMO
One other variable has its own rule: FORCE_HYPERLINK reads a number, so only 0 turns it off. Each variable’s row also states its own rule.
Standard OpenTelemetry exporter variables (OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_HEADERS, OTEL_METRIC_EXPORT_INTERVAL, OTEL_RESOURCE_ATTRIBUTES, and signal-specific variants) are also supported. See Monitoring for configuration details. Set CLAUDE_CODE_ENABLE_TELEMETRY and the OpenTelemetry variables that turn on export, choose its destination, or capture content in your shell, user settings, or managed settings. Claude Code ignores them in project and local settings, apart from the off values that section describes. OTEL_RESOURCE_ATTRIBUTES and the export interval, timeout, and compression variables, such as OTEL_METRIC_EXPORT_INTERVAL, still apply from project and local settings.

What the subprocess environment scrub removes

When you set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB to 1, Claude Code removes credentials from the environments of the subprocesses it starts, such as Bash commands, hooks, and stdio MCP servers. This reduces what a prompt injection attack can read. The Claude Code process keeps the credentials for its own API calls. The scrub recognizes a credential by its variable name or by the shape of its value, so use it as one layer alongside narrow permission rules rather than as the only control. The table shows what the scrub does to example variables: Because the scrub leaves GITHUB_TOKEN in place, give a GitHub Actions job the narrowest permissions it needs. To remove a GitHub token from sandboxed Bash commands, add a deny entry under sandbox.credentials. Leave the scrub unset if a subprocess needs one of the removed variables. On Linux, the scrub also runs Bash subprocesses in an isolated PID namespace so they can’t read host process environments through /proc. As a side effect, ps, pgrep, and kill can’t see or signal host processes. Before v2.1.251, the scrub removed ANTHROPIC_API_KEY and AWS_SECRET_ACCESS_KEY and left the table’s other example variables unchanged.

Features that need feature-flag fetching

Claude Code turns some features on through feature flags it fetches from Anthropic. Claude Code skips that fetch in these sessions:
  • A session where you set DISABLE_GROWTHBOOK, DISABLE_TELEMETRY, DO_NOT_TRACK, or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC; each variable’s row in the variables table says which values turn fetching off
  • A session on a third-party provider, such as Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform, or Microsoft Foundry, unless a host platform that embeds Claude Code sets CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST
  • A Claude apps gateway session
With fetching off, you can’t:

First session after an install or upgrade

In your first session after you install Claude Code, or upgrade to a version that adds a feature, a flag-gated feature can be missing. That session can also start in a different permission mode than your later sessions do. When Claude Code fetches the flags during that session, it saves them on the machine, so your next session on that machine has the feature and the usual starting permission mode. After a fresh install, in a non-interactive session such as claude -p, the Agent SDK, or the VS Code extension, Claude Code can pick the flags up before it chooses the starting permission mode, but it doesn’t always wait for them. In setups such as these, sessions after the first also start without freshly fetched flags:
  • A clean environment on every run: if each run starts in a CI container, or any other environment without the flags an earlier session saved, every run is a first session
  • A gateway token with no API key: if you authenticate with ANTHROPIC_AUTH_TOKEN and no API key, and ANTHROPIC_BASE_URL points at a host other than Anthropic’s, such as an LLM gateway, Claude Code has no credential to fetch the flags with
To choose the permission mode that sessions in these setups start in, see Start in a different permission mode.

See also