Cursor CLI - All models except "auto" fail with "Connection lost, reconnecting..." resource_exhausted

[Daniel_Weil]

Environment

• OS: WSL2 (Ubuntu) on Windows 11
• Cursor CLI version: 2026.02.27-e7d2ef6
• Same subscription on another machine (Windows PowerShell): Works fine
• Same subscription on another machine (different PC): Works fine

Problem

Cursor CLI works perfectly in Windows PowerShell on the same PC, and also works on a completely different PC.
However, inside WSL on this machine, it fails.

What works:

• agent --version
• agent login (already logged in)
• agent --list-models (lists all models)
• agent --model auto (sometimes works briefly)

What fails:

• agent --model gpt-5.4-fast
• agent --model gpt-5.2-codex-fast
• agent -p "prompt"
• agent -c "prompt" (cloud mode)

All failing commands show:

Connection lost, reconnecting...
Retry attempt 1...
Connection lost, reconnecting...
Retry attempt 2...
Connection lost, reconnecting...
Retry attempt 3...
v: [resource_exhausted] Error

WSL Networking Details

• WSL /etc/resolv.conf uses Tailscale DNS: nameserver 10.255.255.254, search tail987dcf.ts.net
• nslookup api.cursor.sh returns “Can’t find api.cursor.sh: No answer”
• Regular cursor.com resolves fine
• Basic network connectivity to cursor.com works (curl -I succeeds)

What I’ve Tried

1. Fresh CLI reinstall (curl https://cursor.com/install` -fsS | bash`)
2. Reset local state (cleared .cursor, .cursor-server)
3. Tried HTTP/1 mode (useHttp1ForAgent: true in config)
4. Tested both interactive and non-interactive modes
5. Tested cloud mode (agent -c)

All produce the same resource_exhausted error after reconnect attempts.

Workaround

Using Cursor CLI from Windows PowerShell (not WSL) works perfectly on this same machine.

---

Expected: Cursor CLI should work in WSL the same way it works in Windows PowerShell

Actual: WSL fails with reconnect/resource_exhausted errors while Windows PowerShell works

[mohitjain (Mohit)]

Daniel,

This appears to be an unreliable DNS resolution issue in your WSL environment. From your post:

• nslookup api.cursor.sh → “Can’t find api.cursor.sh: No answer”

The CLI needs to resolve Cursor’s API hostname to connect to the backend. In your WSL instance, DNS is routed through Tailscale MagicDNS, and it intermittently fails to resolve api.cursor.sh. Short-lived calls (like agent --list-models) can succeed during brief “good” windows, but streaming inference needs a stable connection. When DNS resolution or routing hiccups mid-stream, the connection drops, and you end up in the [resource_exhausted] retry loop.

This also explains why Windows PowerShell works fine: it uses the Windows host resolver, not WSL’s /etc/resolv.conf.

Step 1: Fix DNS in WSL

1. Edit /etc/resolv.conf in WSL:

sudo nano /etc/resolv.conf

Add a public resolver above the Tailscale entry:

nameserver 1.1.1.1
nameserver 10.255.255.254

2. Prevent WSL from overwriting resolv.conf on restart:

sudo nano /etc/wsl.conf

Add:

[network]
generateResolvConf = false

3. Restart WSL from PowerShell:

wsl --shutdown

Then reopen your WSL shell.

4. Verify DNS:

nslookup api.cursor.sh

If that resolves consistently, try the CLI again.

Step 2: If you still see drops after DNS is stable

There’s a separate known HTTP/2 transport issue with some CLI versions. Make sure useHttp1ForAgent is set in the correct config file: ~/.cursor/cli_config.json (not VS Code settings).

{
  "network": {
    "useHttp1ForAgent": true
  }
}

Restart the CLI after changing this.

Let me know how things look after Step 1 (especially whether nslookup api.cursor.sh is consistently resolving in WSL).

Best,
Mohit