Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Fix false “tunnel closed” detection
Root cause (verified)
The ssh tunnel binds the host loopback (127.0.0.1:3307, ssh pid 1712468 — verified via ss outside the sandbox). The Cursor Shell sandbox runs in an isolated network namespace, so any sandboxed command probing 127.0.0.1:3307 gets Connection refused and ss shows only sandbox-internal listeners. That is why timeout 1 bash -c ‘</dev/tcp/127.0.0.1/3307’ reports “closed” even when the tunnel is up — persistently, every session.
Two reliable signals:
The ssh process is visible to pgrep/ps inside the sandbox (process list is not namespaced) → sandbox-safe existence check.
A true reachability probe (/dev/tcp) and the actual mysql connection must run with required_permissions: [“all”] so they execute in the host namespace where the tunnel exists (verified: probe returns 3307 OPEN outside the sandbox).
Changes
- .cursor/rules/shell-grep-permissions.mdc (always-applied — guarantees every future session inherits the fix)
Under the “Network & Sandbox” section, add a short subsection stating:
The sandbox is a separate network namespace; host loopback SSH tunnels (127.0.0.1:3307/3308) are unreachable from sandboxed commands, so a plain /dev/tcp or nc/ss probe yields a false negative.
Detect tunnel liveness sandbox-safely with the process list: pgrep -af ‘ssh.*-L *3307’ (and 3308).
Any command that actually talks to the tunnel (the /dev/tcp reachability probe AND every mysql call) MUST use required_permissions: [“all”].
- .cursor/skills/query-db/SKILL.md — “Tunnel gate” (lines ~20-35)
Replace the current probe guidance with:
Primary sandbox-safe check via process:
pgrep -af ‘ssh.*-L 3307’ >/dev/null && echo “prod tunnel process up” || echo “prod tunnel process not found”
pgrep -af 'ssh.-L *3308’ >/dev/null && echo “dev tunnel process up” || echo “dev tunnel process not found”
Authoritative reachability probe, noting it must run OUTSIDE the sandbox (required_permissions: [“all”]):
timeout 2 bash -c ‘</dev/tcp/127.0.0.1/3307’ 2>/dev/null && echo “prod reachable” || echo “prod unreachable”
One-line callout: a sandboxed probe always reports closed even when the tunnel is up (network namespace isolation).
Also annotate the “Bash + mysql” section (lines ~100-121) that every mysql invocation against the tunnel runs with required_permissions: [“all”].
- .cursor/skills/debug-quickwash/SKILL.md — Step 2 (lines 106-111)
Update the Prerequisite — SSH tunnel must be running. probe block the same way: replace the bare /dev/tcp lines with the pgrep process check + an [“all”]-permission reachability probe, and add the namespace-isolation note. Leave the cloud auto-start ssh -fN … -L commands unchanged (those launch the tunnel; only the in-sandbox readiness for loops should be flagged to run outside the sandbox, or switched to pgrep). Note in the mysql examples that they require required_permissions: [“all”].
Out of scope
No code changes to the API/app. This only corrects agent operational docs/rules so detection stops producing false negatives. After this, I can resume the QUI-310 investigation and actually query the DB (with [“all”]).
Steps to Reproduce
create ssh tunnel on db and agent will run command to detect if tunnel is up, and it fails to identify ssh tunnel that is actually running
Expected Behavior
echo “=== ss for 3307 OUTSIDE sandbox ===”; ss -tlnp 2>/dev/null | grep 3307 || echo “(no 3307 in ss even here?)”; echo “=== /dev/tcp probe OUTSIDE sandbox ===”; timeout 2 bash -c ‘</dev/tcp/127.0.0.1/3307’ 2>&1 && echo “3307 OPEN” || echo “3307 closed/err”
TRue
Operating System
Linux
Version Information
from previous post
For AI issues: which model did you use?
opus 4.8
Does this stop you from using Cursor
No - Cursor works, but with this issue