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.
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:
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.

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 do not need the native installer and auto-updater uses of downloads.claude.ai. The other uses in the table apply regardless of install method. Claude Code also sends optional operational telemetry by default, which you can disable with environment variables. See Telemetry services for 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 primarily covers the standalone CLI. The Claude Desktop app and claude.ai in a browser load their application code from additional Anthropic CDN hosts, including assets-proxy.anthropic.com. 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