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
- 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.
- 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.
- -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).
- -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.