Claude Code Env Vars Don't Persist: 3 of 80 Runs Fell Back to Prod

I told Claude Code export APP_ENV=staging. My next message said to run the script. It printed target = production.

Nothing got deployed. target.py is a one-line stub in a throwaway repo, built around os.environ.get("APP_ENV", "production"), a default you've probably seen in real code. But Claude Code env vars don't persist between Bash tool calls, and I wanted to know how often that actually lands. So I ran 97 headless sessions and counted.

export, source .venv/bin/activate, functions, aliases and umask all vanish before the next call.cd is the exception, and only when the command succeeds and stays inside the project. In subagents it didn't carry at all.env in settings.json for plain values, a SessionStart hook writing to $CLAUDE_ENV_FILE for a virtualenv. Claude Code env vars don't persist because each Bash tool call starts a new shell, so anything held in shell memory dies with that call. Only the working directory is tracked across calls.

I set eight kinds of state in one call and read them back in the next. All 3 runs gave identical results.

You can see it for yourself with one command:

claude -p 'Make two separate Bash calls, one at a time: first "export FOO=1", then "echo FOO=$FOO". Show me the second output verbatim.' --allowedTools Bash

It comes back FOO= with nothing after the equals sign.

The trap is that row at the bottom. cd working makes the tool feel like one long terminal session, so you assume the rest of your shell came along too.

cd persists in the main session when the command succeeds and ends inside the project. Break either condition and the shell stays where it was.

The subagent row is the sneaky one. cd sub prints nothing and exits 0, then the next call is back at the root. A relative path written after that lands somewhere you didn't plan. Subagents do start in the main session's current directory, though: after cd sub in the parent, a subagent's first pwd was proj/sub in 2 of 2 runs.

Rarely. Across 80 runs of ordinary-sounding tasks on Sonnet 5.5, Claude ended up with the wrong environment 3 times, and all 3 involved a variable with a silent default.

The model knows this rule. It wrote export APP_ENV=staging && python3 target.py, re-exported in each command, and briefed subagents with the variable spelled out in their prompt. That last part surprised me. I expected delegation to be the weak spot, and it scored 20 of 20.

The misses came from two places:

export APP_ENV=staging as its own call, did eight other things, then ran a bare python3 target.py. APP_ENV=staging on its own. Twice it ran the bare command. That second miss is partly on me, and I think it's the realistic one. You skim the reply, type the next instruction, and move on.

All 3 misses were reported in the final reply. "It was not set when target.py ran." That sentence is useful after a read-only script. After terraform apply it's a postmortem.

Ten runs per pattern is too small to quote as a failure rate. The finding I'd trust is the split: 3 misses in 50 variable runs, 0 in 30 venv runs. A missing dependency throws ModuleNotFoundError. A missing variable with a default throws nothing.

Set them before the session starts, since nothing Claude runs mid-session survives the call. I tested four ways.

Plain values: use env in settings. It's the smallest fix.

{ "env": { "APP_ENV": "staging" } }

It can't run anything, though. With this alone, python3 still resolved to /usr/bin/python3 and check.py died with ModuleNotFoundError.

Virtualenvs and anything that needs a script: use a hook. Whatever it appends to $CLAUDE_ENV_FILE applies to every later Bash call, subagents included.

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "printf 'source \"%s/.venv/bin/activate\"\\nexport APP_ENV=staging\\n' \"$CLAUDE_PROJECT_DIR\" >> \"$CLAUDE_ENV_FILE\""
      }]
    }]
  }
}

Use >>, so you don't wipe what another hook wrote. Put per-developer values in .claude/settings.local.json and keep secrets out of anything committed.

No, not in anything I tried. The env file behaves as a snapshot taken at session start.

export APP_ENV=edited-midsession, confirmed it with cat, and the next call still said staging. Same result in 2 of 2 runs. If you need to switch from staging to prod, restart the session. For a single command, ask for the inline form: APP_ENV=prod python3 target.py.

No, and this is the cheapest fix in the post. All 3 misses needed a fallback to go wrong quietly.

target = os.environ.get("APP_ENV", "production")

target = os.environ["APP_ENV"]

The second line turns every miss in that table into a crash before any work happens. Default to the safe environment if you must have a default. Anything an agent can run should fail loudly on missing config.

Claude Code 2.1.318 on macOS with zsh, headless claude -p with Sonnet 5.5, project settings only, 97 sessions at about $2.08 of list-price usage. I didn't measure interactive sessions, other models or Linux, so run the one-liner above on your own setup first.

No. Claude Code env vars set with export in one Bash tool call are gone by the next, along with activated virtualenvs, functions, aliases and umask, because every call starts a fresh shell. Only cd carries over, and only in the main session on a successful command that stays inside the project. Claude works around this most of the time (77 of 80 runs here), but for anything that matters, define the state before launch with env in .claude/settings.json or a SessionStart hook that appends to $CLAUDE_ENV_FILE, and remove production defaults from your scripts.

Written by the developer behind Preterview, an interview prep platform.