Remote SSH: agent `WebFetch` hangs until abort; NAS curl and `WebSearch` succeed

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Remote SSH, the agent’s native WebFetch tool can hang with no result and no timeout. The chat spinner stays up until I hit Stop (User aborted request). Other tools in the same turn (Read/Grep) never finish either, so the whole step looks frozen.

This is not a dead remote uplink. From the same Synology host, curl to the same URLs returns in under a second. WebSearch in the same remote session also returns quickly. Cursor Agent Exec.log does not record the WebFetch URL or duration.

The hang is unreliable, not “WebFetch never works over SSH.” The same day, WebFetch of small static docs (jellyfin.org) completed, while GitHub release HTML and Docker Hub API URLs hung until abort. It is not specific to Discourse/forum pages.

This looks distinct from the existing SSH threads about browser MCP not propagating tools, plugin MCP init timeouts, and Undici ~300s MCP header timeouts. Those either fail with an error or are a different tool. Here WebFetch never returns and Stop is the only way out. Possible contributing factors: WebFetch has no timeout in the tool schema; an easy-to-miss fetch approval over SSH; fetch work running on the client/cloud rather than the NAS (so host curl cannot see the stall).

Environment

  • Client: Cursor desktop on LAN (macOS data-os="mac" on cursor.com HTML from NAS curl).
  • Remote: Synology DS425+, DSM 7.4.1, cursor-server 3.20.17 (0c32194e3fb5ffaced9fb36430b860ec301e1fc0).
  • extensionHost --useHostProxy=false --dns-result-order=ipv4first
  • No HTTP_PROXY. IPv6 on, no global IPv6.
  • MCP: cursor-ide-browser listed; stdio MCP sandbox supported=false.

Steps to Reproduce

  1. Cursor desktop → Remote SSH to Synology DSM (or any Linux NAS) with cursor-server on the host.
  2. Agent chat in that workspace.
  3. Ask for a page that is not a tiny static doc (GitHub release HTML, Docker Hub, Discourse). Agent uses WebFetch.
  4. Observe: spinner / no tool result; parallel Read/Grep in the same turn never complete; Stop → User aborted request.
  5. On the same host: curl -L --max-time 8 <url> returns quickly.
  6. Same agent: WebSearch returns quickly.
  7. Optional: WebFetch of a small docs page (e.g. jellyfin.org docs) may still succeed — hang is not 100%.

Expected Behavior

WebFetch returns markdown or a timed error (e.g. 15–30s). Cancel should abort the in-flight fetch.

Operating System

Linux

Version Information

Version: 3.20.17
VS Code Extension API: 1.128.0
Commit: 0c32194e3fb5ffaced9fb36430b860ec301e1fc0
Date: 2026-09-12T03:16:10.634Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

Grok-4.6 high

For AI issues: add Request ID with privacy disabled

RequestID: 9b3343e7-8df1-4629-8e8f-d1ce1f988b59

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey @koliyo, thanks for the detailed report and the request ID.

The fetch itself is completing fine - what you’re hitting is a permissions stall on our side, not the network. When a page is large, the agent first saves the result to a file under ~/.cursor/projects/.../agent-tools/ on the remote host, and because your Synology home is symlinked that write gets treated as outside your workspace, waiting on an approval that never surfaces on the WebFetch step. Small pages return inline, which is why it only hangs sometimes. We’ve let the team know and it’s an issue we’re tracking.

Workaround: in Cursor Settings → Agents → Execution and Approvals, turn off External-File Protection (it appears when your agent is in an Auto-Run mode), then start a new chat and retry the same fetch. It should return in a few seconds. You can turn it back on later if you’d rather keep those prompts.

Could you confirm it returns after that? That’ll tell us the diagnosis holds on your setup.

7

Thanks for response, the file protection workaround seems to work. But it sounds like there is a bug regarding “waiting on an approval that never surfaces on the WebFetch step” since I never get an approval dialog