Desktop model catalog filtered since June 29, but web works (same account)

Support Bug Reports
,
19

Update: After extensive testing, the official HTTP/1.1 workaround
(disableHttp2 + http.proxy + proxySupport:override + proxyStrictSSL:false)
did NOT reliably fix the issue.

Here’s what I found:

WHAT WORKS:

  • Downgrading to 3.7.42 restores the full model list reliably.
    No extra configuration needed — it just works with the system proxy.

WHAT DOESN’T WORK (on 3.9.16):

  1. The 4-line settings.json workaround:

    • First launch: model list came back (seemed fixed)
    • After restart: back to 5 models only
    • Inconsistent behavior

  2. Adding --proxy-server flag:

    • Cursor’s Chromium processes go through proxy (verified)
    • But always-local-singleton still connects directly

  3. Setting HTTP_PROXY / HTTPS_PROXY / ALL_PROXY env vars:

    • singleton still bypasses them

ROOT CAUSE (confirmed via process-level network inspection):
Using lsof to inspect Cursor’s processes on 3.9.16:

  • Cursor main process: connections via 127.0.0.1:7897 (proxy) ✓
  • always-local-singleton: connections via real local IP (DIRECT) ✗

The singleton connects to Cursor backend IPs (Cloudflare / AWS)
using the real local IP, bypassing both the system proxy and
http.proxy setting. This exposes the CN IP, triggering regional
filtering on the model catalog.

The disableHttp2 setting does NOT affect the singleton’s network
stack — it continues to use its own HTTP/2 connection that ignores
all proxy config.

WHY TUN IS NOT VIABLE:
TUN mode conflicts with Tailscale (which I use for remote access
to my dev machine). Both create virtual network interfaces that
compete for the default route, causing network instability.

This is a common setup for users who need:

  • Remote access to their dev machine
  • Corporate VPN compatibility
  • Screen sharing

CONCLUSION:
The always-local-singleton in 3.8+ uses an isolated network stack
that ignores ALL application-layer proxy settings (http.proxy,
system proxy, env vars). Only TUN (network-layer) can intercept
it, but TUN is not viable for users with Tailscale/VPN conflicts.

3.7.42 works because its singleton uses HTTP/1.1 and respects
the system proxy. This is not a version preference — it’s the
only version where the catalog request actually goes through
the proxy.

Could the team make always-local-singleton respect http.proxy /
system proxy again, like in 3.7.42? This would fix the issue
without requiring TUN mode.

Currently stuck on 3.7.42, missing all updates since 3.8.