Cursor Enterprise Network Proxy Configuration: Complete Guide from HTTP_PROXY to Certificate Import

You click Send, and Cursor’s Agent panel pops up a Network error. Your global proxy is clearly enabled, so why can’t it connect?

The answer lies in Electron v25+‘s network stack—Cursor, VS Code, and the operating system each use their own proxy configurations, completely separate from one another. This article walks through enterprise network proxy configuration from start to finish: HTTP_PROXY environment variables, settings.json proxy configuration, HTTP/2 protocol compatibility issues, SSL certificate import, and Anygress transparent proxy. We cover Windows, Mac, and WSL2 environments.

Why Doesn’t Cursor Inherit System Proxy Settings?

Cursor is built on Electron v25+. Electron’s network stack is the same as Chrome’s, which doesn’t automatically inherit proxy settings from the operating system or parent process. This differs from VS Code—VS Code can read system proxy settings, but Cursor needs its own configuration.

Environment variables add another layer of complexity. When you run export HTTP_PROXY=... in a terminal and then launch Cursor from the Dock or desktop icon, that variable never gets passed through. The variable only takes effect if you launch the cursor command from that same terminal window.

So the most reliable approach for enterprise networks is to directly modify Cursor’s settings.json.

What Does the Official Documentation Say?

According to Cursor’s Network Configuration documentation, there are three proxy configuration paths for enterprise deployment:

1. Environment variables: HTTP_PROXY, HTTPS_PROXY, NO_PROXY (only effective when launched from terminal)
2. settings.json: http.proxy, http.proxySupport, http.proxyStrictSSL
3. Startup parameters: --proxy-server, --proxy-auto-detect, --disable-http2

Each method has its use cases, which we’ll explore in detail.

HTTP_PROXY Environment Variable Configuration

Environment variables are the most lightweight method, but there’s a prerequisite: Cursor must be launched from a configured terminal.

Windows PowerShell

# Set proxy (with authentication)
$env:HTTP_PROXY = "http://username:[email protected]:8080"
$env:HTTPS_PROXY = "http://username:[email protected]:8080"

# Bypass proxy for local addresses
$env:NO_PROXY = "localhost,127.0.0.1,.internal.corp"

# Launch Cursor from the same terminal
cursor

macOS / Linux

# Bash/Zsh
export HTTP_PROXY="http://username:[email protected]:8080"
export HTTPS_PROXY="http://username:[email protected]:8080"
export NO_PROXY="localhost,127.0.0.1,.internal.corp"

# Launch Cursor
cursor

WSL2 Special Handling

WSL2 has its own virtual network card and isn’t on the same subnet as the Windows host. Windows proxy settings don’t automatically sync into WSL2.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

One approach is to use the graftcp tool for transparent TCP proxying:

# Install graftcp
sudo apt install graftcp

# Configure proxy address (graftcp.conf)
proxy_addr = "192.168.1.100:7890"  # Windows host's proxy address

# Launch Cursor with graftcp
graftcp cursor

Common Pitfalls:

• Launching from Dock/desktop icon → environment variables don’t take effect
• Setting only HTTP_PROXY without HTTPS_PROXY → Cursor API requests (all HTTPS) won’t go through proxy
• Leaving .internal.corp out of NO_PROXY → internal network services also get proxied, slowing them down

If you don’t want to launch from a terminal every time, settings.json configuration is more convenient.

settings.json Proxy Configuration (Recommended Method)

Open Cursor, press Cmd+Shift+P (Mac) or Ctrl+Shift+P (Windows), and type Preferences: Open User Settings (JSON).

Add these items to settings.json:

{
  "http.proxy": "http://username:[email protected]:8080",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": false,
  "http.noProxy": ["localhost", "127.0.0.1", "*.internal.corp"],
  "cursor.general.disableHttp2": true,
  "cursor.general.disableHttp1SSE": true
}

Field-by-field explanation:

Restart to Apply.

After modifying settings.json, you must completely close and reopen Cursor. Just refreshing the window (Cmd+R) won’t reload the network configuration.

Windows Shortcut Startup Parameters:

If you prefer not to modify settings.json, you can add parameters to the shortcut:

cursor.exe --proxy-server="http://proxy.company.com:8080" --proxy-auto-detect --disable-http2

This method is equivalent to settings.json but takes effect on every launch without requiring a restart.

HTTP/2 Protocol Incompatibility and Solutions

Cursor’s Agent functionality relies on HTTP/2 bidirectional streaming. Real-time chat, code completion, and multi-turn conversations all depend on HTTP/2’s persistent connections and streaming.

Here’s the problem: many enterprise proxies don’t support HTTP/2.

SSL inspection proxies like Zscaler and Netskope only handle HTTP/1.1. When Cursor sends HTTP/2 requests to these proxies, they either get truncated, return garbled data, or simply timeout.

Symptoms:

Alibaba Cloud - Top choice for developers, exclusive 15% off for Lighthouse servers

Get 15% Discount →Ad

• Agent panel stuck on “Thinking…”
• Code completion works sometimes, errors other times
• Chat mode works fine, but Agent mode shows all red errors

Solution: Disable HTTP/2 and let Cursor fall back to HTTP/1.1 SSE.

{
  "cursor.general.disableHttp2": true
}

Or via startup parameter:

cursor --disable-http2

After disabling, Cursor uses HTTP/1.1 Server-Sent Events (SSE) for streaming. SSE is unidirectional and less efficient than HTTP/2 bidirectional streams, but offers better compatibility.

One detail: When both --disable-http2 and settings.json’s disableHttp2 are present, the startup parameter takes precedence. If you want to ensure HTTP/2 is disabled, set both.

Based on Cursor Forum feedback, this method resolves Agent issues for most enterprise users. One user reported in Cursor http/2 requests don’t go through proxy setting that Agent functionality was restored after disabling HTTP/2.

SSL Certificate Import (Enterprise Man-in-the-Middle Inspection)

When enterprise proxies perform SSL decryption, they replace the original certificate with their own. Netskope and Zscaler both have this capability.

Cursor tries to connect to cursor.com or api2.cursor.sh, but receives a certificate signed by the enterprise proxy instead of Let’s Encrypt or DigiCert. Validation fails, and the connection drops.

Symptoms:

• TLS handshake timeout
• certificate signature failure
• Agent panel shows CERT_AUTHORITY_INVALID

Method 1: Import Enterprise Root Certificate to System Certificate Store (Windows)

1. Press Win+R and type certmgr.msc
2. Expand Trusted Root Certification Authorities → Certificates
3. Right-click → All Tasks → Import
4. Select your enterprise root certificate file (.cer or .pem)
5. Restart Cursor after completion

This method makes the system trust the enterprise certificate, and Cursor will trust it too.

Method 2: Specify Certificate via Environment Variable (Recommended)

Cursor supports SSL_CERT_FILE and SSL_CERT_DIR environment variables:

# Single certificate
export SSL_CERT_FILE=/path/to/company-root-ca.pem
cursor

# Certificate directory
export SSL_CERT_DIR=/etc/ssl/certs
cursor

This method is more flexible—it doesn’t modify the system certificate store and only affects Cursor.

Method 3: Disable SSL Strict Validation (Not Recommended)

{
  "http.proxyStrictSSL": false
}

This bypasses certificate validation but reduces security. Only use this in test environments, not production.

Mac / Linux Certificate Import:

# Debian/Ubuntu
sudo cp company-root-ca.pem /usr/local/share/ca-certificates/
sudo update-ca-certificates

# macOS
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root-ca.pem

Restart Cursor after importing.

KiloClaw - Managed OpenClaw for enterprise, enabling AI Agent orchestration and smart model routing

Get Started →Ad

Anygress and cursor-api-proxy (Advanced Configuration)

For enterprise networks, remote servers, and private network scenarios, standard proxy configuration isn’t enough. There’s an open-source project cursor-api-proxy (GitHub: anyrobert/cursor-api-proxy) specifically designed for these situations.

Core Principle:

cursor-api-proxy starts a local proxy service that forwards Cursor’s API requests to the real server. In between, it can perform TLS certificate replacement, Tailscale network tunneling, API key injection, and other operations.

Configuration Example:

# Clone the project
git clone https://github.com/anyrobert/cursor-api-proxy
cd cursor-api-proxy

# Configure environment variables
export CURSOR_BRIDGE_TLS_CERT=./macbook.tail4048eb.ts.net.crt
export CURSOR_BRIDGE_TLS_KEY=./macbook.tail4048eb.ts.net.key
export CURSOR_BRIDGE_API_KEY=your-secret-key
export CURSOR_PROXY_URL=http://127.0.0.1:8765

# Start (with Tailscale TLS)
npm start -- --tailscale

Then point Cursor’s proxy to this service:

{
  "http.proxy": "http://127.0.0.1:8765"
}

Use Cases:

• Corporate network blocks direct connections to cursor.com
• Remote servers without public internet access need Tailscale relay
• Need to inject unified API Key into requests (multi-user sharing)
• Private deployment requiring API requests to go through internal gateway

This method is more complex than standard proxy configuration but offers greater flexibility. It’s suitable for teams with DevOps capabilities.

Conclusion

When configuring Cursor proxy in enterprise networks, troubleshoot in this order:

1. First, set settings.json — http.proxy + http.proxySupport: "override"
2. Disable HTTP/2 — If enterprise proxy doesn’t support it, add disableHttp2: true
3. Check certificates — For TLS handshake timeout or CERT_AUTHORITY_INVALID, import enterprise root certificate
4. Use cursor-api-proxy for complex scenarios — Remote servers, private networks, Tailscale tunneling

Common error reference:

After configuration, remember to completely restart Cursor—not just refresh the window.