Agents no longer can access sql connections

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agents are currently unable to issue poweshell commands in windows 11 as psql queries - until today and after several version upgrades i was subjected to.

My workflow has been utterly destroyed to the point where I can almost do nothing.

Previous i relied on the agents abilitity to run adhoc postgres sql queries on the data and this would form the basis of iterative project developemnt. the models excel, particlarly gpt codex models at problem solving with the use of sql queries - I no longe rcan give them the ability to do so.

I will have to roll back as far as I can. It appears that the agent terminals are deliberately hobbled from remote instruction execution no matter what terminal type I configure in settings.json - cmd.exe or powershell -

Someone tell me what’s going on - it seems this is a purposeful “enhancement” that has utterly destroyed the dynamics of my work flow

Version: 2.5.17 (user setup)
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Steps to Reproduce

yes

Expected Behavior

sql queries do not execute for the agent and if they do the agent cannot read them

Operating System

Windows 10/11

Version Information

Version: 2.5.17 (user setup)
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

all models have the same problem

For AI issues: add Request ID with privacy disabled

there is no error message

Does this stop you from using Cursor

Yes - Cursor is unusable

Cursor 2.5: Sandbox Network Access Controls
3

Hey, thanks for the report. This is a known issue with the agent terminal on Windows. The sandbox and the PowerShell wrapper conflict, especially after recent updates.

Try this temporary workaround:

  1. Open Cursor settings Ctrl+Shift+J
  2. Go to Agents and turn off Auto-run in Sandbox
  3. In the same section, turn on Legacy Terminal Tool
  4. Ctrl+Shift+P then Terminal: Kill All Terminals
  5. Fully restart Cursor
  6. Try running your psql requests again

Legacy Terminal Tool bypasses the new wrapper script that causes the issue. Commands will ask for confirmation before running, but they should work normally, including reading output.

Related reports and workarounds:

The team is aware of the Windows sandbox issues. No timeline yet, but reports like this help with prioritization.

If the workaround doesn’t help, can you share:

  • A screenshot of what happens when the agent tries to run a psql command, like an error message or empty output
  • Whether you have a custom PowerShell profile set up

Let me know how it goes.

1 Like
4

see summary post below

5

Conclusion:

the upgrade logic to v2.5.17 is likely damaging Cursor’s settings.json terminal definitions - the “cd $Project_root” is mangled - when the terminal spawns none of my environment setting for SSH and PSQL can be found, nor can the terminal output be read by the agent because the terminal is nowhere anything expects it to be

somewhere around here in settings.json might be where we should be looking for a solution:

"terminal.integrated.copyOnSelection": true,
"terminal.integrated.persistentSessionScrollback": 500,
"terminal.integrated.scrollback": 2000,
"terminal.integrated.shellIntegration.history": 300,
"terminal.external.linuxExec": "zsh",
"files.autoSave": "afterDelay",
"cursor.composer.usageSummaryDisplay": "always",
"cursor.general.enableShadowWorkspace": true,
"terminal.integrated.automationProfile.windows": {
    "path": "powershell.exe",
    "args": ["-NoProfile", "-Command", "Set-Location -LiteralPath 'F:\\ProjectHome'"]
}
7

Further testing - when Agent tries to invoke SSH the error message is

“Pseudo-terminal will not be allocated because stdin is not a terminal.”

SSH used to work for me in agent terminals - something has really been changed.

Further Psql testing reveals:
"This PSQL run did not end with “spawn: Aborted.” The command was started and left running, then moved to the background after the 30s timeout. So the spawn itself succeeded.

But: no output was captured. The log only shows cwd: “f:\ProjectHome” and that it was still running after 33 seconds; there’s no psql result in the log.

So right now: psql starts in the agent terminal, but we’re not seeing its stdout (and it may be hanging or waiting on something).

So the edits to settings.json have helped but not in itself being a cure

9

Thanks for the detailed diagnosis in the posts above, it’s genuinely helpful.

I want to clarify my previous reply: removing terminal.integrated.automationProfile.windows won’t help. Cursor on Windows already ignores this setting and always uses PowerShell for the agent. This is a known limitation.

On the current situation:

psql starts, but output isn’t captured: if Legacy Terminal Tool is already enabled and it doesn’t fully help, try restarting all terminals (Ctrl+Shift+P → Terminal: Kill All Terminals) and then fully restart Cursor. More details and discussion in this long thread: Agent Terminal not working.

SSH “Pseudo-terminal will not be allocated”: try adding -t or -tt to your SSH command to force PTY allocation. Legacy Terminal Tool can also help a bit with SSH sessions.

To move forward, we’ll need:

  • The Request ID from the chat where psql or SSH fails (chat menu → Copy Request ID)
  • Logs from Help → Toggle Developer Tools → Console at the moment the issue happens

The team is aware of the Windows agent terminal issues. Let me know how it goes after these steps.

10

I have had legacy terminal on - it was the first thing I checked - There’s no request id, correlation id, or similar field in that file or in the Shell tool result. If Cursor adds a request id only when it aborts (e.g. in an error payload), we wouldn’t see it here because these runs didn’t abort, they hang with minmal error messaging. Cursor needs to Improve the 2.5.xx terminal execution logging if you want to see more error reporting

Actually, regarding terminal config, I have been able to configure cmd.exe to run as the Agent terminal, and psql and ssh do execute perfectly unlike powershell.exe – the problem with that was Agent was unable to read the cmd.exe terminal output.

Now testing Cursor version 2.5.20 update – I sent in my settings.json entire configuration to Neil @ support so they know exactly my settings right now – here is the complete output from a new psql test run using 2.5.20

psql test query:

psql -h theDiode -U mav -d mav -P pager=off -c ‘SELECT 1 AS test, current_database() AS db;’

Agent Analysis:

Here’s what I saw from that run:

Observed:

1. No spawn abort – The command started; there was no “Command failed to spawn: Aborted” or “This operation was aborted.” So the 2.5.20 change appears to have fixed the spawn/abort behavior for this case.

1. Environment – cwd is f:\myproject; the command string is passed through correctly with single-quoted -c and no “extra argument” issues.

1. No output in the log – The terminal file only has metadata (pid, cwd, command, running_for_seconds: 32). No stdout/stderr from psql was written to the log, and the run was still considered “running” at the 30s timeout and was sent to the background.

1. Pseudo-terminal – There were no explicit PTY-related messages in the terminal file (nothing like “Pseudo-terminal will not be allocated” or “stdin is not a terminal”). So we can’t tell from this log whether the agent’s terminal is PTY or non-PTY; we only see that no psql output was captured before the timeout.

Summary: Spawn/abort for this psql invocation appears resolved in 2.5.20, but we still don’t get psql output within 30s—either the process is hanging (e.g. auth or connection) or output isn’t being captured/streamed into the terminal log. If you run the same command in your own Cursor terminal and it returns instantly, the remaining issue is likely how the agent’s terminal captures or streams output (or a timeout that’s too short for the first connection).

And yes my terminal responds to Psql instantaneously –

Once again let me clearly state, the Postgres Database we are talking to exists on a server on my lan, using a different Class C netblock. This is also the same server the agent can no longer run remote commands using SSH, which was also possible prior to 2.5.xx upgrades. Also note my project folder does not reside on C: drive if anything in Cursor code resolves by default to C: for project context it will fail but i dont think this is a problem.

Lastly and this may be important the remote Server is FreeBSD not Linux but I am using ZSH shell for the SSH remote account and postgres is always just Postgres no matter what o/s.

SSH testing under 2.5.20

$ ssh madmin@theDiode
Pseudo-terminal will not be allocated because stdin is not a terminal.

$ ssh -tt madmin@theDiode

$ ssh -t madmin@theDiode
Pseudo-terminal will not be allocated because stdin is not a terminal.

ssh -tt does not throw an error, but still fails

Agent SSH Analysis:

Why the aborts happen

  1. Stdin is not a terminal

In the agent’s environment, the shell’s stdin is not a real TTY. So when you run ssh user@host (or ssh -t user@host), ssh sees “no terminal” and does not allocate a pseudo-terminal.

  1. No PTY + waiting on input → abort

Once the connection is up, ssh may try to read the passphrase from stdin (or do other TTY-dependent behavior). In a non-PTY context that can mean “waiting on stdin.” It looks like the runner that starts the agent’s terminal treats that as an invalid or stuck state and aborts the process instead of letting it run.

  1. -tt changes the path

-tt means “allocate a PTY no matter what.” So ssh forces a pseudo-terminal. The runner then either provides a PTY or the process behaves in a way that doesn’t trigger the abort. So we get no abort and the process runs (and then waits for passphrase as expected).

  1. -t isn’t enough

-t is “allocate a PTY if possible.” In the agent’s environment it seems “possible” is still “no,” so we stay in the no-PTY path and get the same abort as with plain ssh mevadmin@theNode.

So the SSH “failures” are really: spawn is aborted when ssh runs in no-PTY mode and then waits on input; using -tt forces a PTY and avoids that abort.

Practical takeaway

  • For agent-run SSH to theNode: use ssh -tt mevadmin@theNode so the spawn isn’t aborted.

  • The remaining limitation is that the User still can’t supply the passphrase; that part is unchanged and would need an agent-side SSH key without passphrase or a different auth setup.

Previously I had SSH passphrase automatically configured but a FreeBSD user account password was needed as input for execution, by me as the final authority - copy paste into the agent terminal – an now agent treminals have been made READ ONLY again it seems.

So there is still a lot of reasons why Cursor 2.5.xx agent terminal is useless for people managing remote Unix servers - which I am sure it’s clear none of the development team is actually doing, from a Windows device running cursor

To me it also seems that Enterprise features have leaked into ordinary developers workspaces, and the network controls are in effect, with no way for me as a standalone user to bypass or turn them of.

13

I have had to down grade to Version: 2.3.35 to reclaim SSH and PSQL remote connectivity

Version: 2.3.35 (user setup)
VSCode Version: 1.105.1
Commit: cf8353edc265f5e46b798bfb276861d0bf3bf120
Date: 2026-01-13T07:39:18.564Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200