Skip to main content
Claude Code supports various enterprise network and security configurations through environment variables. This includes routing traffic through corporate proxy servers, trusting custom Certificate Authorities (CA), and authenticating with mutual Transport Layer Security (mTLS) certificates for enhanced security. Set these environment variables before you launch Claude Code. Variables exported in your shell are read once at startup, so a running session doesn’t pick up later changes to your shell environment.
All environment variables shown on this page can also be configured in settings.json.

​
Proxy configuration

​
Environment variables

Claude Code respects standard proxy environment variables. In Claude Desktop sessions where the app manages the provider connection, Claude Code reads them only from managed settings and ~/.claude/settings.json; see mTLS authentication for the scope rules.
Lowercase variants also work, and Claude Code uses the first one that’s set in the order https_proxy, HTTPS_PROXY, http_proxy, HTTP_PROXY.
Claude Code does not support SOCKS proxies.

​
Basic authentication

If your proxy requires basic authentication, include credentials in the proxy URL:
Avoid hardcoding passwords in scripts. Use environment variables or secure credential storage instead.
For proxies requiring advanced authentication (NTLM, Kerberos, etc.), consider using an LLM Gateway service that supports your authentication method.

​
CA certificate store

By default, Claude Code trusts both its bundled Mozilla CA certificates and your operating system’s certificate store. Reading the OS store requires a runtime with tls.getCACertificates: the native installer always has it, and npm installs need Node 22.15 or later. On older Node versions, only the bundled set and NODE_EXTRA_CA_CERTS apply. Enterprise TLS-inspection proxies such as CrowdStrike Falcon and Zscaler work without additional configuration when their root certificate is installed in the OS trust store and the runtime can read it. CLAUDE_CODE_CERT_STORE accepts a comma-separated list of sources. Recognized values are bundled for the Mozilla CA set shipped with Claude Code and system for the operating system trust store. The default is bundled,system. To trust only the bundled Mozilla CA set:
To trust only the OS certificate store:
CLAUDE_CODE_CERT_STORE has no dedicated settings.json schema key. Set it via the env block in ~/.claude/settings.json or directly in the process environment.

​
Custom CA certificates

If your enterprise environment uses a custom CA, configure Claude Code to trust it directly:

​
mTLS authentication

For enterprise environments requiring client certificate authentication:
Claude Code reads the certificate and key files at startup and re-reads them each time it applies settings, including when settings change during a session. To rotate the certificate and key, replace the files at the same paths. In cloud sessions, the hosting environment manages the connection to the API, so Claude Code ignores the following variables when they come from a settings file env block:
  • CLAUDE_CODE_CLIENT_CERT
  • CLAUDE_CODE_CLIENT_KEY
  • CLAUDE_CODE_CLIENT_KEY_PASSPHRASE
  • NODE_EXTRA_CA_CERTS
  • NODE_TLS_REJECT_UNAUTHORIZED
  • CLAUDE_CODE_OAUTH_SCOPES
Claude Code notes each ignored key in the session’s debug log. In Claude Desktop sessions where the app manages the provider connection, such as the Code tab on a third-party provider and Cowork sessions, Claude Code reads these variables and the proxy variables HTTP_PROXY, HTTPS_PROXY, and NO_PROXY only from managed settings and ~/.claude/settings.json: it ignores them in a repository’s own settings files, so a checked-out repository can’t redirect the TLS or proxy path of a session whose credentials come from the app. In a local, SSH, or WSL Code tab session signed in through claude.ai, the app doesn’t manage the connection, and Claude Code reads these variables from every settings scope, like any terminal session; cloud sessions follow the cloud-session rules above wherever you start them. Before v2.1.217, Claude Code ignored these variables in every settings file when the app managed the connection.

​
Verify your configuration

You usually find out about a wrong proxy address or a bad certificate path from a connection or certificate error on a later request, since Claude Code doesn’t validate most of these settings when it reads them. The one setting it checks at startup is the proxy URL: when it can’t parse the value, such as one missing the http:// scheme, Claude Code stops launch with an error naming the variable to fix. To confirm your configuration loaded before you send a request, start Claude Code with debug logging:
Debug output goes to ~/.claude/debug/<session-id>.txt rather than the terminal, or to a path you set with --debug-file <path>. In the log, look for the lines that confirm each file loaded:
If Claude Code can’t read one of these files, the log shows a Failed to read or Failed to load line with the reason instead. You can also run /status in an interactive session and check these rows:
  • Proxy: shows the active proxy URL, and marks a value it can’t parse as invalid and ignored.
  • mTLS client cert and mTLS client key: appear only when the files loaded, so a missing row means the load failed and the debug log has the reason.
  • Additional CA cert(s): shows the NODE_EXTRA_CA_CERTS path without checking that the file loaded, so confirm this one in the debug log.

​
Apply network settings to background agents

Background agents don’t run inside the terminal that dispatched them. A per-user supervisor process starts on demand, outlives your shell, and hosts every claude agents, --bg, and /background session. See How background sessions are hosted. This changes how the configuration on this page reaches those sessions.

​
Set network variables in settings, not the shell

The supervisor is one process shared by every terminal. It inherits the environment of whichever shell starts it first, and an OS-installed supervisor receives no shell environment at all. If you export a proxy, CA path, or mTLS variable only in your shell, it reaches background agents when that shell happened to cold-start the supervisor, and silently doesn’t when a different shell did. Put the same variables in the env block of ~/.claude/settings.json or managed settings instead. Every variable on this page can be set there, and settings are the only configuration that reaches every background session on every machine.

​
Configure a corporate launcher as a setting

Some organizations require every Claude Code process to start through a corporate launcher that applies sandboxing, network controls, or credential injection. The supervisor and its workers start Claude Code from a fixed path rather than by looking up claude on PATH, so every background agent bypasses a wrapper you place earlier on PATH. Set the processWrapper setting to prefix the supervisor, its workers, and the other background processes listed under What the launcher covers with your launcher. The equivalent CLAUDE_CODE_PROCESS_WRAPPER environment variable takes precedence when both are set, and it is subject to the same rule: deliver it through managed settings or ~/.claude/settings.json, not a shell export. Run Claude Code behind a corporate launcher covers the contract the launcher must satisfy, what it does and doesn’t reach, and how to roll it out.
An already-running supervisor keeps the launch configuration it started with. After deploying the launcher setting, run claude daemon stop --any so the next claude agents or --bg starts a supervisor that honors it. An installed service takes claude daemon stop without --any.

​
Network access requirements

Claude Code requires access to the following URLs. Allowlist these in your proxy configuration and firewall rules, especially in containerized or restricted network environments. If you install Claude Code through npm or manage your own binary distribution, end users don’t need the native installer and auto-updater uses of downloads.claude.ai, but npm and bun installs need their package registry, registry.npmjs.org, unless your organization mirrors it. The other uses in the table apply regardless of install method. The two Datadog intake hosts carry only optional operational telemetry, and setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC disables both. Sessions on third-party providers never send to these hosts, even when a platform sets CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST and telemetry metrics default on. See Telemetry services for everything Claude Code sends and how to disable it before finalizing your allowlist. When using Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, or a signed-in Claude apps gateway session, model traffic and authentication go to your provider or gateway instead of api.anthropic.com, claude.ai, or platform.claude.com. The WebFetch tool still calls api.anthropic.com for its domain safety check unless you set skipWebFetchPreflight: true in settings. When routing through an LLM gateway with ANTHROPIC_BASE_URL, the fast mode availability check still calls api.anthropic.com rather than the gateway base URL. The check does honor a configured HTTP proxy, so where a network block is the cause, an allowlist entry for api.anthropic.com in the proxy is the fix. A network block fails the check only where the host is unreachable even through the proxy, and fast mode then reports a connectivity error. The same connectivity error appears when the check presents a gateway-issued credential that Anthropic rejects; allowlisting doesn’t help there, since nothing is blocked. See use fast mode behind proxies and LLM gateways for the variables that restore it. Claude Code on the web and Code Review connect to your repositories from Anthropic-managed infrastructure. If your GitHub Enterprise Cloud organization restricts access by IP address, enable IP allow list inheritance for installed GitHub Apps. The Claude GitHub App registers its IP ranges, so enabling this setting allows access without manual configuration. To add the ranges to your allow list manually instead, or to configure other firewalls, see the Anthropic API IP addresses. For self-hosted GitHub Enterprise Server instances behind a firewall, allowlist the same Anthropic API IP addresses so Anthropic infrastructure can reach your GHES host to clone repositories and post review comments.

​
Desktop and claude.ai

The preceding table covers the standalone CLI. The Claude Desktop app and claude.ai in a browser load their application code and user content from additional Anthropic CDN hosts, including assets-proxy.anthropic.com and the *.claudeusercontent.com origins that serve artifacts. Allowing claude.ai while blocking those hosts produces a blank page rather than an error. See network access requirements on the Desktop page.

​
Additional resources