Whenever I ask my agent to access my VPS, it skips SSH; I’ve already enabled all access, run everything, set up allowlists, and so on, but nothing works.
The Agent’s terminal is non-interactive by design, so it cannot open a live SSH session into your VPS. Anything that waits for a password or drops into a remote shell prompt will be skipped or will fail, and auto-run or allowlist settings do not change that (they only control which commands run without approval).
Two ways to get what you want:
Ask the agent to run one-shot, non-interactive commands, for example: run ssh -o BatchMode=yes user@your-vps 'uptime'. This needs key-based authentication set up so there is no password prompt. If the command fails with a “network blocked” message, approve network access when prompted, or add ssh to your allowlist.
For real work on the VPS, connect Cursor to it directly with Remote-SSH: press Cmd+Shift+P, choose “Remote-SSH: Connect to Host”, pick your VPS, and open your project folder there. The agent then runs directly on the VPS and no ssh commands are needed at all.
The one-shot SSH approach is correct—the block isn’t about interactivity or sandboxing.
The command ssh -o BatchMode=yes sdr-vuca '…' didn’t even leave this machine. Cursor rejected it again with “production requires approval.” That is a production classifier, distinct from the Run Mode. “Run Everything (Unsandboxed)” only bypasses terminal/sandbox approval; it doesn’t authorize SSH access to a production host.
What you described (network blocked / allowlist) is a separate gate. In this case, the production card is being automatically denied within this chat.
The code remains ready: 6f6a4e3 on branch feat/abertura-formulario-campanha, with a local archive at /tmp/sdr-6f6a4e3.tar.gz.
For me to proceed with the deployment from here, the production card needs to be accepted when it appears. The alternative suggested by support—opening the VPS folder via Remote-SSH and having the agent work there—also works, since that avoids using SSH from the local terminal.
With Run Everything (Unsandboxed) enabled, the agent still never opened a TCP connection. The tool call was blocked locally by Cursor before ssh ran. The exact payload was:
What we did not see (so it wasn’t sshd / key / network):
no Permission denied
no Connection refused / timeout / Host key verification failed
no Network blocked prompt
no remote stdout at all (not even HOST_OK)
Auth is key-based (Host sdr-vuca, IdentityFile ~/.ssh/id_ed25519, user ubuntu). The same one-shot style works from a normal local terminal.
So this is a client-side production classifier, not sshd rejecting the session. “Run Everything” is not bypassing production requires approval in this chat. Retrying with request_smart_mode_approval was also auto-denied with the same reason — the approval card never actually got accepted.
If Run Everything is supposed to skip that gate, this looks like a bug: the production policy is still intercepting ssh to a known prod host.
Hey @Rubens_Marques, thanks for the extra detail, that pinned it down.
It looks like that message is coming from a Hook configured in your Cursor setup. Hooks are small scripts that run before the agent executes a command and can block it. Hooks apply in every run mode, including Run Everything, by design, so changing the run mode will not get around one.
One important note: hooks like this are often configured centrally by an admin on your team (for example, to guard against commands touching production), so it may not be something you set up yourself, and it may not be something you can change on your own.
To find it:
Press Cmd/Ctrl + Shift + P and type Open Customize. Any configured hooks are listed under the Hooks section.
Also check for a hooks file in these two places: .cursor/hooks.json inside your project folder, and ~/.cursor/hooks.json in your home directory.
Look for an entry under beforeShellExecution or preToolUse that points to a script. Open that script and search for “production requires approval”.
If the hook is yours, you can either remove that entry or edit the script so it allows your sdr-vuca host (or returns "permission": "ask" instead of deny, so you get a prompt to approve). Then start a new chat and try the ssh command again.
If it turns out the hook was set by your admin or comes from a shared/managed config, you will need to reach out to whoever owns it to get sdr-vuca allowlisted, rather than editing it locally.
I’ve reached my monthly usage limit, but I’d prefer not to switch to API-based usage.
What I would like to do is simply pay for another month of my current plan — around R$200 — so I can continue using the included models, such as Grok, Composer, and the other models available through the subscription.
Would it be possible to cancel or reset my current subscription so that I can subscribe again immediately and pay for another monthly allowance, instead of having to use the API?
If there is another way to renew or purchase another month of usage before my current billing cycle resets, that would also work for me.