[Bug] always-local-singleton ignores http.proxy and server overrides cursor.general.disableHttp2

Support Bug Reports
1

Description

Since Cursor 3.9.16, AI model requests are handled by the always-local-singleton utility process. This process does not honor the IDE’s http.proxy or http.proxySupport settings — it makes direct connections using Node.js native http2.connect() / https.request() without a proxy agent.

Additionally, even when cursor.general.disableHttp2 is explicitly set to true, a server-side value (lastServerHttp2DisabledValue) can silently override it back to false, forcing HTTP/2 connections that have no proxy support at all.

Environment

  • Cursor 3.9.16, macOS (likely affects all platforms)
  • Corporate network requiring outbound traffic through a proxy
{
  "cursor.general.disableHttp2": true,
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxyStrictSSL": false,
  "http.proxySupport": "override"
}

Steps to Reproduce

  1. Configure http.proxy in Cursor settings
  2. Set cursor.general.disableHttp2 to true
  3. Use any Claude model in Chat or Agent mode
  4. Observe “Model not available — This model provider is not supported in your region”

The Two Issues

1. Singleton process ignores http.proxy

The always-local-singleton process calls https.request(url, options) without passing an agent. Unlike the main Electron process, it does not read or respect the proxy configuration. All requests go direct.

Verified via lsof: the singleton establishes TCP connections directly to Cursor API servers (Cloudflare IPs), bypassing the configured local proxy entirely.

2. Server overrides user’s disableHttp2 setting

In alwaysLocalSingletonMain.js, when the server returns lastServerHttp2DisabledValue of 2 or 4, the code evaluates to false (HTTP/2 enabled) — ignoring the user’s explicit true setting. Since http2.connect() has zero proxy support in Node.js, this makes the proxy bypass unavoidable even for users who correctly configured both proxy and HTTP/1.1.

Expected Behavior

  • The always-local-singleton process should honor http.proxy and http.proxySupport, consistent with how the main Electron process handles proxy settings
  • cursor.general.disableHttp2: true should not be overridden by a server-side value

Related Threads

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Since Cursor 3.9.16, AI model requests are handled by the always-local-singleton utility process. This process has two issues:

  1. Ignores http.proxy setting — It calls https.request(url, options) and http2.connect() without a proxy agent, making direct connections that bypass the configured http.proxy entirely.

  2. Server overrides cursor.general.disableHttp2 — Even when the user explicitly sets disableHttp2: true, a server-returned value (lastServerHttp2DisabledValue = 2 or 4) silently re-enables HTTP/2. Since http2.connect() has no proxy support in Node.js, this makes proxy bypass unavoidable.

Result: “Model not available — This model provider is not supported in your region.” when using Claude models behind a corporate proxy.

Steps to Reproduce

  1. Set up a corporate network environment where outbound traffic must go through a proxy
  2. Configure Cursor settings:
    {
  "cursor.general.disableHttp2": true,
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxyStrictSSL": false,
  "http.proxySupport": "override"
}
  3. Open Cursor 3.9.16, select any Claude model in Chat or Agent mode
  4. Send a message
  5. Observe the “Model not available” error

Verification via terminal:

lsof -i TCP -a -p $(pgrep -f "always-local-singleton") -n | grep ESTABLISHED

This shows direct TCP connections to Cloudflare IPs (e.g. 104.18.19.125:443), confirming the singleton process bypasses the configured proxy.

Expected Behavior

  • The always-local-singleton process should honor http.proxy and http.proxySupport settings, consistent with how the main Electron process handles them.
  • cursor.general.disableHttp2: true should not be overridden by a server-side value.

Screenshots / Screen Recordings

Error message displayed in Cursor:

Model not available
This model provider is not supported in your region. Visit Regions | Cursor Docs for more information.

Operating System

MacOS

Version Information

Cursor 3.9.16 (Electron 40.10.3)

For AI issues: which model did you use?

Claude Opus 4.6 (affects all Claude models)

For AI issues: add Request ID with privacy disabled

N/A — requests fail before reaching the API due to proxy bypass.

Does this stop you from using Cursor?

Yes - Cursor is unusable (all Claude models fail behind corporate proxy)

7

I can confirm this issue also exists on Windows.

After upgrading to Cursor 3.9.16, the configured SOCKS5 proxy is no longer respected for AI requests in some cases, even though other network requests still go through the proxy. As a result, I receive the error:

“This model provider is not supported in your region.”

The exact same proxy and account work correctly with older Cursor versions, so this appears to be a regression introduced in newer releases rather than a proxy configuration issue.

8

hey @z_m, indeed it seems like it might not be that simple, pulled from the answer, see :

it’s which IP the catalog request goes through.

9

If you use WireShark to inspect the packet you could see Cursor 3.9.* actually leaking connection without following the proxy specially for api2.cursor.sh.
Right now, just downgrade back to 3.8.24 and disable update.

10

I really don’t want to use global TUN mode or downgrade the version. For Linux users, I’ve provided a script to solve this issue. I don’t use Windows or macOS myself, but the general approach should be the same, so you can adapt it for those platforms.

13

disable gate features：
decompose_always_local_ext_host
cursor_extensions_isolation_v2

14

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

i’ve problem in newer version 3.9.16 with connection trough proxy, seems the connection doesn’t goes trough anymore which result to error :
Cursor Network Diagnostic Results

FAILED (5): SSL, API, Ping, Chat, Agent

DNS: Success
Logs:
[2026-06-30T09:21:53.070Z] Host: api2.cursor.sh
[2026-06-30T09:21:53.070Z] Servers: 192.168.155.38,192.168.155.36
[2026-06-30T09:21:53.070Z] Resolved to 100.51.80.46 in 1ms
[2026-06-30T09:21:53.164Z] Resolved to 100.51.80.46 in 94ms
[2026-06-30T09:21:53.167Z] Resolved to 100.51.80.46 in 1ms
[2026-06-30T09:21:53.167Z] Resolved to 100.51.80.46 in 0ms
[2026-06-30T09:21:53.187Z] Host: api2.cursor.sh
[2026-06-30T09:21:53.187Z] Servers: system
[2026-06-30T09:21:53.187Z] Resolved to 34.197.247.23, 100.51.80.46, 34.198.42.18, 32.197.70.219, 23.20.96.163, 54.92.228.128, 54.236.191.220, 34.236.52.0 in 6ms
[2026-06-30T09:21:53.190Z] Resolved to 34.197.247.23, 100.51.80.46, 34.198.42.18, 32.197.70.219, 23.20.96.163, 54.92.228.128, 54.236.191.220, 34.236.52.0 in 0ms
[2026-06-30T09:21:53.191Z] Resolved to 34.197.247.23, 100.51.80.46, 34.198.42.18, 32.197.70.219, 23.20.96.163, 54.92.228.128, 54.236.191.220, 34.236.52.0 in 0ms
[2026-06-30T09:21:53.192Z] Resolved to 34.197.247.23, 100.51.80.46, 34.198.42.18, 32.197.70.219, 23.20.96.163, 54.92.228.128, 54.236.191.220, 34.236.52.0 in 0ms
[2026-06-30T09:21:53.192Z] Result: true

SSL: Error: read ECONNRESET
Logs:
[2026-06-30T09:21:53.047Z] Start
[2026-06-30T09:21:53.382Z] Error: read ECONNRESET in 335ms

API: Error: [aborted] read ECONNRESET
Logs:
[2026-06-30T09:21:53.049Z] Start
[2026-06-30T09:21:53.502Z] Error: ConnectError: [aborted] read ECONNRESET

Ping: Error: [aborted] read ECONNRESET
Logs:
[2026-06-30T09:21:53.049Z] Sending ping 1
[2026-06-30T09:21:53.502Z] Error: ConnectError: [aborted] read ECONNRESET

Chat: Error: [aborted] read ECONNRESET
Logs:
[2026-06-30T09:21:53.050Z] Starting streamSSE
[2026-06-30T09:21:53.501Z] Error: ConnectError: [aborted] read ECONNRESET

Agent: Error: [aborted] read ECONNRESET
Logs:
[2026-06-30T09:21:53.050Z] Starting stream
[2026-06-30T09:21:53.051Z] Pushing first message
[2026-06-30T09:21:53.500Z] Error: ConnectError: [aborted] read ECONNRESET

Steps to Reproduce

also i’ve tested on many clients and tried a few proxies with same result

Expected Behavior

it expected to connect via proxy and network test results successful

Operating System

Windows 10/11

Version Information

Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

18

Hey all - thanks for the detailed reports and digging here. This is one issue, not several.

On 3.9.x, AI/model requests moved to a new connection path that defaults to HTTP/2, and HTTP/2 traffic doesn’t currently go through a configured proxy. The request then reaches us from your real IP, which shows up either as “model not available in your region” (the catalog is filtered by the request’s IP) or as connection resets on proxy-only networks. It’s a confirmed 3.8 → 3.9 regression and we’re tracking it.

The best lever today is to force HTTP/1.1, which does honor your proxy. Set all four together (use your own proxy address/port), then fully quit and relaunch (Cmd+Q, not Reload Window):

{
"cursor.general.disableHttp2": true,
"http.proxy": "``http://127.0.0.1:7890``",
"http.proxySupport": "override",
"http.proxyStrictSSL": false
}

Being honest: some of you are still seeing this behave inconsistently even on HTTP/1.1 - that’s the same root cause, and a proper fix isn’t out yet, so I don’t have an ETA. Downgrading works as a stopgap but you’ll miss updates.

More testing on the “desktop shows only 5 models” symptom is in this thread.

19

I don’t know who used this script, but I’ve identified all the domains officially listed by Cursor, making my script more reliable. I hope the two friends who liked this post see this message.

20

My solution for this bug is to close Cursor.

Rename or delete these folders:

  • %USERPROFILE%\.cursor

  • %APPDATA%\Cursor

Then, open Cursor. However, after a few hours, the bug reappears, and you will have to apply this workaround again.

21

Thanks for sharing - please don’t treat wiping those folders as a fix.

Renaming or deleting %APPDATA%\Cursor and %USERPROFILE%\.cursor removes chat history, settings, and extensions, and the relief is only temporary (as you saw - it comes back after a few hours).

If you’re on a Team or Enterprise plan: fully quit Cursor (not Reload Window) and relaunch. That path was adjusted on our side recently, and a clean restart is usually enough - no need to wipe folders.

Everyone else: stick to the HTTP/1.1 settings in my earlier reply. Force HTTP/1.1 with your proxy, then quit and relaunch. That keeps your data intact while we finish the real fix.