Environment variables are the most powerful and the bluntest tuning lever: they act globally on the process, and sometimes on its subprocesses. So it helps to split them into two categories. The first is the working core teams actually touch: provider, authentication, model mapping. The second is diagnostic, cloud and compatibility switches touched rarely and for a specific reason. This reference gives a map of the most important variables by group; the full documented index is on the official env-vars page.

Provider and authentication are the first and most important group. ANTHROPIC_API_KEY has authentication precedence and can quietly switch from a subscription to API billing; ANTHROPIC_BASE_URL redirects to a gateway; CLAUDE_CODE_USE_BEDROCK and CLAUDE_CODE_USE_VERTEX enable cloud providers, and ANTHROPIC_DEFAULT_*_MODEL maps aliases to deployment IDs. Mixing several providers' variables in one shell is not allowed - /status here is mandatory evidence of where the traffic goes.

The other groups are touched pointwise. Behavior and limits: MAX_THINKING_TOKENS, CLAUDE_CODE_MAX_OUTPUT_TOKENS. Platform: CLAUDE_CODE_GIT_BASH_PATH for Windows, USE_BUILTIN_RIPGREP for your own rg, CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE for updating via the manager. Telemetry: CLAUDE_CODE_ENABLE_TELEMETRY and the OTEL_* family. Mechanisms: ENABLE_TOOL_SEARCH for MCP tool search, CLAUDE_CODE_DISABLE_CRON for the scheduler. Below is a map of the key variables by group.

The main rule of this reference: a variable's presence in the index does not mean advice to enable it. Many exist for support, migrations, cloud providers or emergency diagnostics, and a variable enabled without understanding is access or behavior you did not notice you set. Be especially careful with switches that disable checks and telemetry. The exact set and behavior depend on the version and provider, so you check the official page, and verify the actual effect via /status and claude doctor.