Agent-shell sandbox DNS resolution broken: /run/systemd/resolve/ not exposed, dangling /etc/resolv.conf symlink
Cursor client: 3.1.17 (Universal), commit fce1e9ab7844f9ea35793da01e634aa7e50bce90, macOS (Darwin arm64 25.4.0)
Remote server: same commit fce1e9ab…, Ubuntu 22.04 on AWS (linux 6.8.0-1044-aws)
Tools affected: any tool using the libc resolver — gh, curl, aws, docker pull, etc., all fail with Could not resolve host, even with full_network permission granted to the Shell tool.
Repro (inside an agent Shell call with full_network):
$ ls -la /etc/resolv.conf
lrwxrwxrwx 1 nobody nogroup 39 Oct 15 2025 /etc/resolv.conf → ../run/systemd/resolve/stub-resolv.conf
$ cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory
Regression: this worked in past sessions. Something just changed within the last few minutes, I upgraded cursor to the latest version, restarted it, tried various things, but I’m getting the same behavior over and over.
Steps to Reproduce
Ask an agent to curl any web page. Note if it uses its WebFetch tool, things work, but if it needs to directly use the curl CLI, it will fail.
I can reproduce this, and I’m honestly a bit surprised we don’t have more reports. If your theory is correct, this should affect any Linux system using systemd-resolved (which is most Ubuntu/Debian setups)!
Would you know what version of Cursor you upgraded from?
@Colin Thank you for confirming. Here is a screenshot of the version I was at first. To be clear I was hitting the issue on this version too. I upgraded in an attempt to address the error, but the upgrade to 3.1.17 didn’t change the behavior. So I’m not sure what changed when the problem started occurring.
I just upgraded Cursor but no change. I’m still blocked on doing a large category of work—anything requiring the agent to access the internet through non-builtin tools like WebFetch.
Thanks for the update @hashr47. I’m not aware of a specific fix that landed between those versions for this issue.
Could you confirm which Auto-run Mode you have set in Cursor Settings > Agent > Auto-run? If it’s set to “Auto-run in sandbox”, the DNS issue should still be present. If it’s set to a non-sandboxed mode, that would explain why things are working.
@Colin You are correct. The problem still exists. Yes, to confirm I have “Auto-run in sandbox” as my setting.
I misreported. I was working on a different project yesterday that is local on my Mac. As you stated earlier, this problem is on Linux machines, so it only occurs for me when I’m in a remote SSH session.
@Colin I noticed that I only hit this issue when I’m in Ask mode. In Agent mode, there is no problem. I don’t know if that was the case before. At least I do have a workaround now. It’s not ideal because when I’m asking my AI to make network calls is often exactly when I want to be in the safer Ask mode.
I only hit this issue when I’m in Ask mode. In Agent mode, there is no problem.
Actually I am hitting this issue in Agent mode also. Not sure if I’m doing something different on different days or if the behavior is genuinely inconsistent.
@d10r Thanks for confirming. This is the same known bug.
@hashr47 Thanks for the update. Good to know it affects Agent mode too. The inconsistency you’re seeing may depend on whether a particular command goes through the sandboxed terminal path or not.
Workaround for both of you: In Cursor Settings > Agents, switch from “Auto-run in sandbox” to a non-sandboxed auto-run mode. This bypasses the sandbox entirely, so DNS works normally. The trade-off is losing the sandbox’s security protections for terminal commands, which I understand might not be ideal.
Setting auto-run outside the sandbox isn’t acceptable in my environment.
The workaround I’m currently using is to use a bespoke http proxy so the dev process can talk to localhost and not require DNS. But it’s a bit cumbersome because requiring explicit proxying for every endpoint a sandbox process wants to talk to. If anybody can figure out a smoother workaround, please let us know.
PS: is there a way to use the cursor subscription (included inference) with other harnesses (e.g. opencode) until this is fixed?
