Claude Code Environment Variables

Claude Code environment variables are shell variables that let you control how Claude Code authenticates, behaves, and connects to your system, and this guide explains the practical ones to know, when to use them, and where they fit if you are working with Claude Code as an independent reference rather than Anthropic documentation.

• The short answer
• How it works
• What you’d actually do with it
• Vs. the alternatives
• Other questions readers ask
• The honest take

The short answer

Claude Code env variables are configuration values you set in your terminal before launching Claude Code so it can pick up credentials, choose endpoints, respect your shell setup, and behave consistently across local machines, remote dev boxes, and team workflows. They are most useful for developers who want predictable setup, safer secret handling, or automation around coding tasks.

• What it does: passes config and secrets into Claude Code
• Where it runs: your shell, terminal, dev container, CI, or remote host
• What it costs: Claude Code itself is part of Claude plans; API use follows per million token pricing where applicable
• Who it’s for: developers who want repeatable local setup and automation

The key idea is simple: instead of hard-coding settings into scripts or typing them every session, you export environment variables once and let Claude Code read them at runtime. That is standard developer practice because it separates code from secrets and makes it easier to move between laptops, containers, and shared repos.

If you are still getting oriented, it helps to first understand the broader product in our Claude Code guide, the main Claude features overview, and the difference between app plans and developer billing on the Claude pricing page. Claude the product is made by Anthropic, but c-ai.chat is an independent guide.

How it works

Environment variables work by exposing name-value pairs to a process at launch time. When you start Claude Code from a shell, it can read values that are already present in that session. Common examples in developer tools include API credentials, preferred endpoints, logging flags, proxy settings, and paths to local config files.

In practice, most developers set Claude Code env variables in one of four places: directly in the current terminal with export, in a shell profile such as .zshrc or .bashrc, inside a project-specific .env workflow, or through container and CI configuration. The right choice depends on whether the setting is personal, project-scoped, or meant for automation.

The workflow matters because different settings have different risk levels. Non-sensitive preferences can live in shell config. Secrets should usually stay out of repos and be injected through a secret manager, encrypted environment store, or local shell session. If your team uses Claude through app plans, Claude plans cover Claude Code access on the product side, while programmatic usage may also involve the Claude API depending on the setup you are building.

1. Open the shell where you run Claude Code

   Use the same terminal app, dev container, or remote machine that will launch the tool. Environment variables only exist where you set them.

2. Export the variable

   For a one-session test, use a command such as export VARIABLE_NAME=value. This is the safest way to verify behavior before making it persistent.

3. Start Claude Code in that same session

   Launch Claude Code after the variable is set so the process can read it at startup.

4. Check the result with a simple task

   Ask Claude Code to inspect a repo, explain a file, or propose a patch. If a variable controls auth or network access, failures usually appear immediately.

5. Move stable settings into a persistent config path

   Once confirmed, place non-secret values in your shell profile or team environment setup. Keep secrets out of Git and rotate them if they were ever exposed.

There is also a practical split between variables Claude Code reads itself and variables it simply passes through to commands it runs in your environment. For example, a proxy variable, Git-related variable, or language-toolchain variable may not be Claude-specific, but it still changes the outcome of what Claude Code can access or execute on your machine.

# one-session example
export VARIABLE_NAME="value"
claude-code

# persistent shell example
echo 'export VARIABLE_NAME="value"' >> ~/.zshrc
source ~/.zshrc

That is why developers often think of Claude Code env variables in two buckets: direct Claude configuration and surrounding system configuration. Both matter. If Claude Code needs authentication, endpoint details, or permission-related behavior, those are direct inputs. If it needs to run Git, see package managers, reach a corporate proxy, or work inside a container, system environment variables shape the result just as much.

What you’d actually do with it

Searchers looking for claude code env variables usually do not want theory. They want concrete use cases: logging in cleanly, switching contexts, running in a container, handling team setup, or making a repeatable script. These are the practical patterns that come up most often.

1. Set credentials without pasting them into scripts

The standard use case is secret handling. Instead of embedding credentials in a script or command history, you inject them through the environment. That keeps sensitive values out of source files and makes rotation easier.

export ANTHROPIC_API_KEY="your-secret-key"
claude-code

If your workflow touches the Anthropic API directly, this pattern is especially common. Anthropic’s platform docs use environment variables for API authentication across examples, and the same principle carries into adjacent developer tooling. Keep the variable local to your user account or your secret store, not committed to a repository.

2. Run Claude Code inside a dev container

Containers are useful when you want every developer to have the same setup. In that model, environment variables are usually declared by the container runtime or compose file, then read when Claude Code starts. This reduces the “works on my machine” problem and keeps project setup consistent.

services:
  app:
    environment:
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - HTTP_PROXY=${HTTP_PROXY}
      - HTTPS_PROXY=${HTTPS_PROXY}

Notice that not every variable is Claude-specific. Proxy variables matter if your company restricts outbound traffic. Language runtime variables matter if Claude Code needs to run tests or project commands. The environment is the operating context, not just an auth vault.

3. Switch between personal and team contexts

Some developers keep separate shells, profiles, or wrapper scripts for different accounts or workspaces. One terminal session may point to a personal setup; another may use company-approved variables, network routes, or credentials. This avoids accidental cross-use and makes audits simpler.

# personal shell
export WORK_CONTEXT="personal"

# work shell
export WORK_CONTEXT="company"
export HTTPS_PROXY="http://proxy.internal:8080"

The specific variable names here are illustrative. The point is the pattern: use environment scope to keep contexts separate. That is safer than constantly editing config files by hand.

4. Make automation repeatable in CI or scripts

If you use Claude-assisted checks, patch generation, documentation drafts, or repo analysis in automation, env variables are the cleanest way to inject credentials and environment-specific values. CI systems are built around this model, and most can mask sensitive output automatically.

5. Control surrounding tools that Claude Code relies on

Sometimes the fix is not a Claude-specific variable at all. If Claude Code is trying to inspect a Node project, run Python tests, or call Git, it inherits the shell environment that those tools need. Variables like PATH, proxy settings, language version manager paths, and repository-related values can decide whether a task succeeds.

export PATH="$HOME/.pyenv/shims:$PATH"
export GIT_AUTHOR_NAME="Your Name"
export GIT_AUTHOR_EMAIL="[email protected]"
claude-code

This is one reason Claude Code can feel different from browser-based chat. In the app, the environment is mostly hidden. In a terminal workflow, your machine state is part of the product experience.

For budgeting, remember that app plans and API billing are separate ideas. Claude’s user-facing plans include Free at $0/month, Pro at $20/month or $17/month annual, Max from $100/month, Team Standard at $25/seat/month or $20/seat/month annual, Team Premium at $125/seat/month or $100/seat/month annual, and Enterprise with a $20/seat base plus usage at API rates. API model pricing starts at $1/M input and $5/M output for Haiku 4.5, $3/M and $15/M for Sonnet 4.6, and $5/M and $25/M for Opus 4.7. You can compare the current official numbers on Claude pricing and our independent pricing explainer.

If your Claude Code workflow reaches the API under the hood or sits next to your own API tooling, cost controls matter. Anthropic also offers Batch API pricing at 50% off both input and output, which can be relevant if you are automating large background jobs rather than using an interactive coding session.

Vs. the alternatives

Claude Code environment variables are not unusual. Most serious coding assistants and developer CLIs use the same pattern. The difference is less about the existence of env vars and more about how much of your workflow lives in the terminal, how transparent the tool is about shell context, and how much control you want over local execution.

Tool type	How env vars matter	Strength	Trade-off
Claude Code	Central for auth, shell context, automation, containers, and inherited tooling	Good fit for terminal-first developers who want explicit control	Requires comfort with shell setup and secret hygiene
IDE-native assistants such as Cursor	Often hidden behind app settings, with some env use for advanced setup	Smoother UI for editor-centric workflows	Can feel less transparent when environment or network issues appear
GitHub Copilot-style editor integrations	Usually lighter direct env management for basic use	Fast onboarding inside supported editors	Less shell-level control for custom automation patterns
Repo-aware coding tools such as Cody	Env vars are common for enterprise auth, self-hosting, or proxy scenarios	Useful when codebase indexing and team search matter most	Setup can grow complex in managed environments

The practical trade-off is this: if you want something that feels more like a standard terminal tool, environment variables are a feature, not a burden. If you want everything hidden behind a graphical settings panel, a CLI-centric workflow may feel more technical than necessary. Neither approach is automatically better.

Claude is strongest when you want to combine model capability with explicit developer control over files, shell context, and repeatable setup. If your use case is mostly browser chat, start from the main Claude AI guide or the broader feature breakdown rather than optimizing shell variables too early.

Other questions readers ask

The honest take

Claude Code env variables are not a special trick. They are the normal way to make a terminal-based coding tool reliable, portable, and safer to operate. If you are comfortable in the shell, they make Claude Code much easier to use across machines, projects, and automation. If you are not, they can feel like setup overhead until you need repeatability.

The best approach is to keep it simple: use environment variables for secrets and machine-specific configuration, keep non-sensitive defaults documented, and verify exact variable names against Anthropic’s current docs before building scripts around them. That gives you the control benefits without turning basic usage into a configuration project.

Independent guide. Not affiliated with Anthropic. For the official Claude product, visit claude.ai.

Last updated: 2026-05-12