# 10 Claude Code Env Vars Worth Exporting, and Why DISABLE_TELEMETRY=0 Still Disables It > Source: > Published: 2026-10-25 07:01:45+00:00 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](https://code.claude.com/docs/en/env-vars). A lot of the tuning that changes how [Claude Code](https://code.claude.com/docs/en/overview) behaves lives on that page. Ten of those variables follow. Every name and default comes from that page and the [model configuration docs](https://code.claude.com/docs/en/model-config), 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](https://code.claude.com/docs/en/settings)). 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. 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. 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.* 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. 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. 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. 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. 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. 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](https://code.claude.com/docs/en/authentication#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.* 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. 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. 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](https://hermes-ide.com), 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](https://hermes-ide.com/download) or read the source on [GitHub](https://github.com/hermes-hq/hermes-ide). | Variable | Default | Try | |---|---|---| | `BASH_DEFAULT_TIMEOUT_MS` | 120000 | 300000 | | `BASH_MAX_OUTPUT_LENGTH` | 30000 | 80000 | | `ANTHROPIC_MODEL` | your account's default | `sonnet` | | `CLAUDE_CODE_SUBAGENT_MODEL` | unset (inherit) | `haiku` | | `CLAUDE_CODE_EFFORT_LEVEL` | model default | `high` | | `MAX_THINKING_TOKENS` | unset | `0` (not on 5.5 models) | | `CLAUDE_CODE_MAX_OUTPUT_TOKENS` | varies by model | 64000 | | `CLAUDE_CONFIG_DIR` | `~/.claude` | `~/.claude-work` | | `DISABLE_AUTOUPDATER` | unset | `1` | | `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` | unset | `1` | 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. 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](https://www.amazon.com/dp/B0GX38N645) 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](https://hermes-ide.com/download) keeps each task's agent, model and effort in one place.