On macOS, Normal Chat works reliably, but the Agent / Composer window (and the agent CLI) hangs indefinitely on “planning response” and fails with repeated reconnect attempts:
│ Connection lost, reconnecting to https://agentn.global.api5.cursor.sh… RetriableError: [unavailable] PING timed out
│
│ Cross-Platform Isolation:
│ Using the exact same Cursor user account on the exact same cellular mobile hotspot network, a Windows laptop works 100% seamlessly for both Chat and Agent, whereas macOS
│ consistently fails on the Agent endpoint.
│
│ Root Cause:
│ The Agent’s Connect-RPC transport sends HTTP/2 PING keepalive frames to agentn.global.api5.cursor.sh. On macOS, when the Wi-Fi network has no public IPv6 WAN route, macOS maintains
│ active link-local utun virtual interfaces with default IPv6 routes (fe80::%utun*). When dual-stack DNS returns AAAA records, the keepalive PING frames get routed into dead utun
│ tunnels, triggering a PING timed out error. Windows NCSI avoids this by disabling IPv6 lookups when no WAN gateway is detected.
Steps to Reproduce
│
│ 1. Connect a macOS machine to a mobile hotspot or Wi-Fi network that only has IPv4 internet routing.
│ 2. Open Cursor and submit any prompt in Normal Chat (Note: this succeeds).
│ 3. Open Composer / Agent (Cmd + I) and submit a prompt, or run agent -p “test” in the terminal.
│ 4. Observe the prompt hanging for ~3 minutes before throwing:
│ RetriableError: [unavailable] PING timed out or HTTP/1.1 SSE responses are being buffered by a proxy in your network environment.
Expected Behavior
│ The Agent window and CLI should maintain an active streaming socket over IPv4 (matching Windows behavior) or gracefully fall back to HTTP/1.1 / application-level heartbeats when
│ HTTP/2 PING frames are dropped.
the failure occurs at the Connect-RPC transport layer to agentn.global.api5.cursor.sh before model execution.
For AI issues: add Request ID with privacy disabled
N/A (Fails at transport connection / handshake level before request ID generation: [internal] AI connect transport unary call cancelled for
aiserver.v1.ServerConfigService.getServerConfig)
Additional Information
Renderer Log Excerpt:
[info] Agent URLs changed from server config, updating cursorCreds {“newNonPrivacyUrl”:“https://agentn.global.api5.cursor.sh”}
[error] Failed to refresh server config from server: [internal] AI connect transport unary call cancelled for aiserver.v1.ServerConfigService.getServerConfig
[error] Draft workspace archived: Error: Draft workspace archived
Hey, thanks for the detailed report, and especially for comparing Windows vs macOS on the same hotspot. That’s a really useful clue.
One quick note on the theory. Our agent endpoint agentn.global.api5.cursor.sh only publishes IPv4 addresses, it has no AAAA records. So HTTP/2 PING frames ride on the already established TCP connection and can’t “jump” into a separate tunnel. But if your Mac is still getting IPv6 answers for this domain, then something local is synthesizing them. That’s often hotspot DNS, like carrier DNS64 on cellular, a local DNS filter, a VPN, or iCloud Private Relay. Our Node HTTP/2 transport doesn’t do happy-eyeballs fallback to IPv4, so a single “bad” AAAA answer can hang the whole stream. Short requests like Chat and Network Diagnostics still work, but the long agent stream doesn’t. That matches what you’re seeing.
To confirm, two things would help:
On this hotspot, run Cursor Settings > Network > Run Diagnostics and send which checks fail using the Copy diagnostics button.
Temporarily disable IPv6 on your Mac Wi-Fi: System Settings > Wi-Fi > Details > TCP/IP > Configure IPv6 > Link-Local Only, then try Agent again.
If it works with IPv6 off, that confirms the address selection theory and we can dig further from there. Also for the test, please close any VPN apps and Private Relay. Leftover tunnel interfaces like utun can black-hole traffic in exactly this way.
Here are the complete diagnostic results from Cursor Settings > Network > Run Diagnostics on this hotspot, along with empirical packet traces from our custom Node.js Connect-RPC client test:
1. Cursor Network Diagnostics Output
Cursor Network Diagnostic Results
FAILED (3): Ping, Chat, Agent
DNS: Success
Logs:
[2026-08-26T13:35:25.963Z] Host: api2.cursor.sh
[2026-08-26T13:35:25.963Z] Servers: 8.8.8.8
[2026-08-26T13:35:25.963Z] Resolved to 100.60.160.158 in 5ms
[2026-08-26T13:35:26.092Z] Host: api2.cursor.sh
[2026-08-26T13:35:26.092Z] Servers: system
[2026-08-26T13:35:26.092Z] Resolved to 100.60.160.158, 52.1.64.163, 54.236.137.71, 184.192.208.29, 3.224.183.72, 54.86.116.38, 54.204.194.206, 100.62.147.48 in 13ms
[2026-08-26T13:35:26.093Z] Result: true
SSL: Success
Logs:
[2026-08-26T13:35:28.674Z] URL: https://api2.cursor.sh/
[2026-08-26T13:35:28.674Z] Status: 200
[2026-08-26T13:35:28.674Z] DNS Time: 3ms
[2026-08-26T13:35:28.674Z] Connect Time: 2086ms
[2026-08-26T13:35:28.674Z] TLS Time: 316ms
[2026-08-26T13:35:28.674Z] Result: true in 2724ms
API: Success
Ping: Error: Response took 2652ms
Logs:
[2026-08-26T13:35:28.787Z] Response: 'ping' in 2836ms
[2026-08-26T13:35:31.481Z] Response: 'ping' in 2694ms
[2026-08-26T13:35:34.149Z] Response: 'ping' in 2668ms
[2026-08-26T13:35:36.858Z] Response: 'ping' in 2709ms
[2026-08-26T13:35:39.510Z] Response: 'ping' in 2652ms
[2026-08-26T13:35:39.510Z] Result: Error: Response took 2652ms
Chat: Error: Streaming responses are being buffered by a proxy in your network environment
Logs:
[2026-08-26T13:35:28.787Z] Response: 'foo' in 2831ms
[2026-08-26T13:35:29.819Z] Response: 'foo' in 1032ms
[2026-08-26T13:35:30.816Z] Response: 'foo' in 997ms
[2026-08-26T13:35:31.814Z] Response: 'foo' in 998ms
[2026-08-26T13:35:32.845Z] Response: 'foo' in 1031ms
[2026-08-26T13:35:33.784Z] Result: Error: Streaming responses are being buffered by a proxy in your network environment
Agent: Error: HTTP/1.1 SSE responses are being buffered by a proxy in your network environment
Logs:
[2026-08-26T13:35:28.876Z] Response: 'foo' in 2920ms
[2026-08-26T13:35:32.180Z] Response: 'foo' in 3304ms
[2026-08-26T13:35:35.443Z] Response: 'foo' in 3263ms
[2026-08-26T13:35:38.762Z] Response: 'foo' in 3318ms
[2026-08-26T13:35:42.065Z] Response: 'foo' in 3303ms
[2026-08-26T13:35:42.065Z] Result: Error: HTTP/1.1 SSE responses are being buffered by a proxy in your network environment
Marketplace: Success (275ms)
Authentication: Success (995ms)
Agent Endpoint: Success (Resolved to 100.30.166.181 in 203ms)
To isolate the issue completely from the IDE UI, we built a standalone Node.js script using native node:http2 to emulate the Connect-RPC protocol directly against https://agentn.global.api5.cursor.sh/agent.v1.AgentService/Run:
Direct Socket & Stream Latencies:
Handshake & TCP connection to 52.74.223.220:443 completed in 232ms.
Sending 5 sequential raw RFC 7540 PING frames received all 5 PING ACK frames in 70ms – 137ms RTT.
When transmitting a 5-byte framed binary envelope with valid Keychain JWT credentials, the initial HTTP/2 200 headers and heartbeat frame arrived in 380ms.
Direct backend response latency was 632ms – 754ms (gemini-3.7-flash-medium, claude-4.6-sonnet-medium).
The Root Cause: Carrier Proxy Chunk Buffering:
The underlying route and TLS socket are fast (<100ms), but the cellular hotspot carrier transparently buffers HTTP/1.1 SSE chunks and flushes them in ~3.3-second batches (Response: 'foo' in 3304ms, 3263ms, 3318ms).
Normal Chat survives because it is a unary request that buffers the entire response and renders all at once, whereas continuous bidirectional Agent streams stall whenever a keepalive or tool frame is held inside the carrier buffer past the client timeout.
Client-Side Error Masking in Connect-RPC:
When decoding stream chunks directly in our script, we found that when the backend returns permission_denied (ERROR_OUTDATED_CLIENT: “Your version of Cursor no longer supports this action”), @connectrpc/connect-node doesn’t fail fast.
Instead, it treats the aborted stream as a transient network disconnect, retries 12 times, and upon exhaustion surfaces RetriableError: [unavailable] PING timed out, masking the actual error.
IPv6 & Tailscale State:
Setting IPv6 to Link-Local Only (networksetup -setv6LinkLocal Wi-Fi) and disconnecting Tailscale (tailscale down to remove utun4 / MagicDNS Request AAAA records) ensured clean IPv4 routing.