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

**URL:** <https://forum.cursor.com/t/desktop-model-catalog-filtered-since-june-29-but-web-works-same-account/164383>\
**Category:** Bug Reports\
**Tags:** openai, anthropic\
**Created:** [June 30, 2026, 2:43am UTC](https://forum.cursor.com/t/desktop-model-catalog-filtered-since-june-29-but-web-works-same-account/164383 "2026-06-30T02:43:21Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![shaotang\_shi](https://avatars.discourse-cdn.com/v4/letter/s/cc9497/32.png) [@shaotang\_shi](https://forum.cursor.com/u/shaotang_shi)\
**Post date:** [June 30, 2026, 8:12am UTC](https://forum.cursor.com/t/desktop-model-catalog-filtered-since-june-29-but-web-works-same-account/164383/19 "2026-06-30T08:12:45Z")

</div>

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:

2. Adding --proxy-server flag:

3. Setting HTTP\_PROXY / HTTPS\_PROXY / ALL\_PROXY env vars:

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.

---

_[View the full topic](https://forum.cursor.com/t/desktop-model-catalog-filtered-since-june-29-but-web-works-same-account/164383)._
