Claude Code 十個值得匯出的環境變數，以及 DISABLE_TELEMETRY=0 仍會停用遙測的原因

• Book: Prompt Engineering Pocket Guide
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

Your agent starts the integration suite. The suite needs four minutes. At the two-minute mark the Bash tool times out, the agent reads a failed command, and it may go hunting for a bug that isn't there.

That two-minute limit isn't a CLI flag. It's BASH_DEFAULT_TIMEOUT_MS, one of the variables on the Claude Code environment variables page. A lot of the tuning that changes how Claude Code behaves lives on that page.

Ten of those variables follow. Every name and default comes from that page and the model configuration docs, as read on October 15, 2026. Claude Code ships often, so check the page again before you copy a value into a team config.

Where to put them: export a variable in your shell and it lasts for that terminal session. Put it under env in a settings file and, in the docs' words, it "applies every time claude runs":

{
  "env": {
    "BASH_DEFAULT_TIMEOUT_MS": "300000"
  }
}

~/.claude/settings.json covers every project, and .claude/settings.json inside a repo is shared with your team (settings docs). One surprise: when your shell and a settings file set the same variable, the settings file usually wins, because Claude Code writes each env entry into its own environment over the inherited value.

Shell commands: how long and how much

1. BASH_DEFAULT_TIMEOUT_MS

The timeout for a foreground Bash command, in milliseconds. Default: 120000, two minutes.

export BASH_DEFAULT_TIMEOUT_MS=300000   # 5 minutes

Want it when your test suite, a container build or a database migration runs longer than two minutes and the agent keeps hitting the limit. Its sibling BASH_MAX_TIMEOUT_MS (default 600000, ten minutes) is the most the model can request for a single command. The effective ceiling is the larger of the two.

2. BASH_MAX_OUTPUT_LENGTH

How many characters of a command's output Claude Code reads back into the result. Default 30000, maximum 150000.

export BASH_MAX_OUTPUT_LENGTH=80000

The line you need often sits at the bottom of a long build log, and that's where the cut lands. Every extra character ends up in the context window, so raise it for the job that needs it. If you set the bashOutputMaxChars setting, Claude Code ignores this variable.

Two limits on every shell command the agent runs: how long it may take, and how much of its output comes back.

Which model, and how hard it thinks

3. ANTHROPIC_MODEL

The model to use, as an alias (opus, sonnet, haiku, fable) or a full model name. On the Anthropic API, opus resolves to Opus 5.5 and sonnet to Sonnet 5.5.

export ANTHROPIC_MODEL=sonnet

Handy for a terminal, CI job or script that should always start on the same model. Know where it ranks: /model in a session and claude --model at startup both beat it, and it beats the model key in your settings.

4. CLAUDE_CODE_SUBAGENT_MODEL

The default model for subagents, agent-team teammates and workflow agents that aren't given a model another way.

export CLAUDE_CODE_SUBAGENT_MODEL=haiku

Use it to keep the main session on a large model while the helpers run on a cheaper one. Two things still beat it: a model Claude passes when it spawns the agent, and a model field in the agent's definition. There's also CLAUDE_CODE_SUBAGENT_MODEL_FORCE if you want every subagent on one model regardless.

5. CLAUDE_CODE_EFFORT_LEVEL

The effort level for supported models: low, medium, high, xhigh, max, or auto for the model's default. Opus 5.5, Sonnet 5.5 and Haiku 5.5 default to medium, and most other models that support effort default to high.

export CLAUDE_CODE_EFFORT_LEVEL=high

Want it when you've settled on one level and want it everywhere. Mind the precedence, which is the opposite of the model variable: this one beats --effort, /effort and the effort settings. It's also the only way to make max stick. Set any other way, max lasts for the current session only. Put it in your shell profile and it overrides every per-session effort choice you make later.

6. MAX_THINKING_TOKENS

A fixed token budget for extended thinking. Read its row carefully, because on current models it does less than the name suggests. Models with adaptive reasoning ignore a positive value and pick their own depth. 0 turns thinking off on the Anthropic API, except on Opus 5.5, Sonnet 5.5, Haiku 5.5 and the Fable models, which can't have thinking turned off.

export MAX_THINKING_TOKENS=0

It earns its place only on a model that can have thinking turned off, when you want short, fast answers. Opus 4.6 and Sonnet 4.6 can go back to the fixed budget with CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1. On the 5.5 models, item 5 is the control that does something.

7. CLAUDE_CODE_MAX_OUTPUT_TOKENS

The maximum output tokens for most requests. Defaults and caps vary by model, and Claude Code lowers a value above a model's cap to the cap. For a model ID it can't resolve, the default is 32000 and the cap is 128000.

export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000

Long single responses, such as a large generated file, are where this bites: they get cut off. It also matters when you route Claude Code to a model it doesn't know. The trade-off, from the docs: a higher value shrinks the context available before auto-compaction runs.

Where it keeps state, and what it sends home

8. CLAUDE_CONFIG_DIR

Overrides the configuration directory, ~/.claude by default. Settings, session history and plugins all live under that path.

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

That alias is the docs' own example for running several accounts side by side. A work account next to a personal one is the obvious case, and so is a clean profile to test a plugin in. Credentials follow their own rules, covered under credential management. Set it in your shell or user settings, with an absolute path in a settings file. Project and local settings ignore it.

One configuration directory per account: separate settings, history and plugins.

9. DISABLE_AUTOUPDATER

Set to 1 to stop automatic background updates. Running claude update yourself still works.

export DISABLE_AUTOUPDATER=1

Release weeks are the usual reason: the version changes when you say so. The stricter DISABLE_UPDATES=1 also blocks manual claude update and claude install, and is aimed at teams that distribute Claude Code through their own channels.

10. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

One switch for nonessential network traffic: auto-updates, telemetry, error reporting, the /feedback command, release notes, PR status badge checks and availability checks. It also turns off feature-flag fetching, so Remote Control and other flag-gated features become unavailable.

export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

Want it on a restricted network, or under a policy that allows model API calls and little else. If you only want one piece gone, DISABLE_ERROR_REPORTING turns off just error reporting. DISABLE_TELEMETRY turns off telemetry and, per its row, feature-flag fetching too. Telemetry events don't include code, file paths or Bash commands.

The trap from the title: "most on/off variables accept 1, true, yes, on and 0, false, no, off, but CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY and DISABLE_ERROR_REPORTING, plus a few others on the page, don't. They check only whether the variable is set, so any non-empty value turns the behavior on, 0 included:"

export DISABLE_TELEMETRY=0   # still opts out
unset DISABLE_TELEMETRY      # back to the default

The docs flag this in bold on each of the three rows. To undo one, unset it or set it to an empty string.

Per task, not per terminal

Items 1, 9 and 10 are set-and-forget (10 only if you don't use Remote Control). Put them in ~/.claude/settings.json and stop thinking about them. Items 2 and 7 cost context, so raise them for the job that needs it. Items 3, 5 and 8 are different: the model, the effort and the account are what you change from one task to the next, and they're the ones that go wrong when you export them once in a shell profile and forget.

I build Hermes IDE, so weigh this with that in mind. Hermes runs Claude Code and other agents each in a real terminal. Its ⌘N task sheet (Ctrl+Shift+N on Windows and Linux) lets you pick the agent, model, effort and account per task, and save the combinations you use often as presets. You can add several accounts per agent.

The ⌘N New task sheet in Hermes: agent, project, worktree, approval mode, model and effort chips, with the "Hermes will run" preview of the claude command.

Two lessons from the list carry over to any launcher. An exported CLAUDE_CODE_EFFORT_LEVEL beats --effort, so a global export overrides whatever effort a launcher passes on the command line. If you pick effort per task, leave item 5 unexported. ANTHROPIC_MODEL works the other way round, and --model beats it. Settings-file env entries still apply, because Claude Code reads them itself "no matter how claude was launched."

Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It isn't affiliated with Anthropic or any other agent vendor. Download it or read the source on GitHub.

The cheat sheet

The full page lists far more than ten, including API_TIMEOUT_MS for slow networks and MCP_TIMEOUT for MCP servers that start slowly. Which one do you set on every machine? Tell me in the comments.

If this was useful

Two of these variables come down to one budget: every character of build log and every output token you allow is context the model can't spend on your instructions. The Prompt Engineering Pocket Guide is about that side of the work, from system prompts and CLAUDE.md-style instructions to context engineering and structured output. If you run more than one agent a day, Hermes IDE keeps each task's agent, model and effort in one place.