How to Configure HTTPS_PROXY for Cursor and Claude Code in Corporate Network

If your company restricts outbound traffic through a corporate proxy, AI assistants like Cursor and Claude Code simply stop responding: autocomplete hangs, the CLI returns ETIMEDOUT or SSL certificate problem. Let's explore how to correctly set the environment variables HTTPS_PROXY, configure authentication, and avoid common mistakes that cause developers to spend hours debugging network settings instead of code.

Why AI Assistants Need a Proxy in a Corporate Network

Cursor and Claude Code are not local models. They constantly access external APIs: Cursor connects to its code indexing servers and model APIs (OpenAI, Anthropic, Google depending on the selected provider), while Claude Code — directly to the Anthropic API via HTTPS. In a corporate network, direct internet access is often blocked by a firewall, and all outbound traffic must go through a proxy server (Squid, Zscaler, Blue Coat, Fortinet FortiProxy, or an internal corporate gateway). Without properly configured environment variables, the application simply does not know that the traffic needs to be routed through the proxy and tries to reach the internet directly — resulting in timeouts.

An additional complexity is that Cursor is built on Electron (essentially Chromium + Node.js), while Claude Code is a Node.js CLI application. Each has its own logic for reading proxy settings: Electron partially inherits system settings from the OS, while Node.js processes read the HTTP_PROXY/HTTPS_PROXY environment variables directly or through libraries like undici and node-fetch. This creates confusion: the settings are configured, but the tool does not "see" them.

HTTP_PROXY, HTTPS_PROXY, and NO_PROXY Variables: How It Works

The classic way to specify a proxy for console Node.js, Python, and Go applications is through environment variables. The difference between HTTP_PROXY and HTTPS_PROXY is fundamental: the former is used for HTTP requests, while the latter is for HTTPS requests (and almost all traffic from AI assistants goes over HTTPS). It is advisable to specify both, even if the actual traffic is only HTTPS — some libraries make service HTTP requests at startup.

export HTTP_PROXY="http://proxy.company.local:8080"
export HTTPS_PROXY="http://proxy.company.local:8080"
export NO_PROXY="localhost,127.0.0.1,.company.local"

Note: even for HTTPS traffic, the proxy address scheme is specified as http://, not https:// — this is the address of the proxy server itself, not the target resource. Connecting to the proxy over HTTP is normal; encryption to the final server still works through the CONNECT tunneling mechanism.

The NO_PROXY variable is needed to exclude internal company addresses from proxying — otherwise, requests to internal git repositories, Jira or local development services will also go through the external proxy and may either not be found or slow down. An important nuance: some libraries are case-sensitive regarding variable names. For reliability, specify both variants — in uppercase and lowercase:

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export no_proxy="$NO_PROXY"

Configuring Proxy for Cursor

Cursor partially uses the system proxy settings of the OS (especially on macOS and Windows), but for stable operation in a corporate network, it is better to explicitly configure it through environment variables and, if necessary, through the application configuration file.

On macOS and Linux, the easiest way is to add the export of variables to the shell profile file so that they are picked up with each terminal launch from which Cursor starts:

# ~/.zshrc or ~/.bash_profile
export HTTP_PROXY="http://user:[email protected]:8080"
export HTTPS_PROXY="http://user:[email protected]:8080"
export NO_PROXY="localhost,127.0.0.1,*.company.local"

After modifying the profile file, run source ~/.zshrc and completely restart Cursor (do not just minimize the window — terminate the process via Activity Monitor or Task Manager, as Electron applications cache the environment at startup).

On Windows, it is more convenient to set the variables through the system environment settings (Control Panel → System → Advanced System Settings → Environment Variables) or through PowerShell for permanent saving:

[System.Environment]::SetEnvironmentVariable('HTTPS_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('HTTP_PROXY','http://user:[email protected]:8080','User')
[System.Environment]::SetEnvironmentVariable('NO_PROXY','localhost,127.0.0.1','User')

If after this Cursor still does not connect to the model APIs, check the proxy settings within the application itself: Settings → Network (or General) — there may be a separate Proxy URL field that overrides the system variables. In some builds of Cursor, it is also necessary to explicitly enable the option "Use system proxy settings."

Configuring Proxy for Claude Code

Claude Code is a CLI tool on Node.js, launched via npm/npx, so it directly reads the environment variables from the terminal session in which it was invoked. This simplifies the setup: just export the variables before running.

export HTTPS_PROXY="http://user:[email protected]:8080"
export HTTP_PROXY="http://user:[email protected]:8080"
claude

If you are running Claude Code as part of a CI pipeline or from a script, pass the variables explicitly in the launch command to avoid dependency on the global shell environment:

HTTPS_PROXY="http://proxy.company.local:8080" \
HTTP_PROXY="http://proxy.company.local:8080" \
claude --print "Check tests in the project"

For persistent configuration, it is more convenient to fix the variables in a .env file at the root of the project and load it via direnv or built-in dotenv support if your shell supports it. This is especially convenient when different projects require different proxy settings (for example, one project works with an internal API, while another works with external services).

Authentication on Corporate Proxy

Most corporate proxies require authentication — Basic Auth, Digest, or NTLM. For Basic Auth, the username and password can be embedded directly in the proxy URL, as shown above: http://user:[email protected]:8080. An important nuance — if the password contains special characters (@, #, %), they need to be URL-encoded; otherwise, the proxy string parser will break at the boundary between the username and host.

# If the password is P@ssw0rd#2024, encode special characters:
# @ -> %40, # -> %23
export HTTPS_PROXY="http://user:P%40ssw0rd%[email protected]:8080"

It is more complicated with NTLM authentication (often used in conjunction with Microsoft ISA Server, Forefront TMG, or Fortinet) — Node.js and most HTTP clients do not support NTLM "out of the box." In this case, the standard solution is to set up a local proxy intermediary that handles the NTLM handshake, and then provides a "clean" HTTP proxy for the application. This is often done using cntlm or px (a local NTLM proxy in Python). The scheme is simple: Cursor/Claude Code → localhost:3128 (cntlm) → corporate NTLM proxy → internet.

# Example configuration for cntlm (/etc/cntlm.conf)
Username    your_login
Domain      COMPANY
Password    your_password_or_hash
Proxy       proxy.company.local:8080
Listen      3128

# After starting cntlm, specify the local address:
export HTTPS_PROXY="http://127.0.0.1:3128"
export HTTP_PROXY="http://127.0.0.1:3128"

Certificates and MITM: SSL Issues in a Corporate Network

If a product like Zscaler, Netskope, or any other web filter with SSL inspection is deployed in the company, the traffic is decrypted at the proxy and signed with a corporate Root CA certificate. Node.js (and therefore Claude Code, as well as most internal modules of Cursor) by default trusts only its built-in set of root certificates and will throw an error UNABLE_TO_VERIFY_LEAF_SIGNATURE or self signed certificate in certificate chain.

The solution is to export the corporate CA certificate (usually it can be obtained from the IT department or exported from the browser's certificate store) and specify the path to it in Node.js via the NODE_EXTRA_CA_CERTS variable:

export NODE_EXTRA_CA_CERTS="/etc/ssl/certs/company-root-ca.pem"

It is highly discouraged to globally disable certificate verification via NODE_TLS_REJECT_UNAUTHORIZED=0 — this removes protection against MITM attacks for the entire process, including legitimate connections. Use this flag only for one-time diagnostics and be sure to restore protection afterward.

Common Errors and Their Solutions

Error	Cause	Solution
ETIMEDOUT / ECONNREFUSED	Proxy variables are not exported in the session where the application is running	Check echo $HTTPS_PROXY in the same terminal, restart the application completely
407 Proxy Authentication Required	Username/password not provided or outdated	Update credentials in the proxy string, URL-encode special characters in the password
self signed certificate in certificate chain	Corporate MITM proxy replaces the certificate	Specify NODE_EXTRA_CA_CERTS with the corporate Root CA
Proxy works in the terminal but not in Cursor	Cursor is launched from the wrong terminal or via a shortcut without environment	Run Cursor using the command from the terminal with exported variables, or set the variables globally in the system
NTLM authentication failed	Client does not support NTLM handshake	Set up an intermediary proxy cntlm or px between the application and the corporate proxy

Testing Connection with curl

Before figuring out why Cursor or Claude Code is not working, make sure that the proxy is accessible and correctly proxies HTTPS traffic. For this, use curl — it reads the same environment variables and allows you to quickly localize the problem without launching heavy applications.

# Check proxy availability and authentication
curl -v -x "http://user:[email protected]:8080" https://api.anthropic.com

# Check considering the corporate certificate
curl -v --cacert /etc/ssl/certs/company-root-ca.pem \
  -x "http://user:[email protected]:8080" \
  https://api.anthropic.com

If curl successfully receives a response (even 401 or 403 — this is normal, meaning the TLS handshake passed), but Claude Code still does not connect — the problem is not with the network, but with the process not seeing the environment variables. If curl also fails with a certificate error or timeout — the issue lies at the network or proxy level, and the tools are not to blame.

When an External Proxy is Needed Instead of Corporate

Sometimes the task goes beyond accessing from the corporate network to the outside. Developers testing integrations with geo-dependent APIs, checking service behavior from different countries, or debugging rate-limit policies of model providers encounter situations where the corporate proxy issues the same corporate IP for all requests. In such scenarios, it is convenient to route test traffic through an external proxy alongside the main working environment.

For stable long-lived test sessions with minimal risk of IP blocking, residential proxies are suitable — they use real IP addresses from home providers and appear as regular user traffic, which is important when checking geo-specific API responses. If you need to replicate the behavior of a mobile client or test scenarios sensitive to network type, consider mobile proxies. For mass parallel testing of requests to public APIs, where speed and cost of traffic are more important than disguising as an ordinary user, datacenter proxies are usually sufficient.

Important: such an external proxy is configured in the same way through the HTTPS_PROXY/HTTP_PROXY variables, but for the test environment or a separate terminal profile, to avoid mixing it with the main working traffic through the corporate gateway. If corporate policy requires that all company traffic goes only through the internal proxy, using an external one must be coordinated with IT/Security — many companies explicitly prohibit bypassing the corporate gateway without permission.

Setup Checklist

Conclusion

Most issues with Cursor and Claude Code behind a corporate proxy boil down to three things: environment variables do not reach the process, authentication is set up incorrectly, or the corporate MITM certificate is not added to the trusted list. By checking these three points in order — through curl, rather than immediately through the application itself — you save hours on debugging and quickly localize the cause.

If the task goes beyond the corporate network and you need to test API behavior from different regions or with different types of IPs, we recommend trying residential proxies — they provide stable and less suspicious traffic for external services compared to regular datacenter addresses.