Agent terminal configuration for remote SSH and Psql sessions

Discussions
, ,
1

Cursor agent terminal lost remote SSH/psql access after updates (Windows) — working fix

Recent Cursor versions repeatedly broke remote ssh and psql access for Agent terminals in my setup.
I got it working again, with trade-offs.

What fixed it

  • Set SSH precedence so the Agent terminal resolves to my newer client first (C:\OpenSSH-GitHub\OpenSSH-Win64\ssh.exe) instead of the Windows built-in one.
  • Enabled key-based SSH via ssh-agent, with my id_ed25xxx key loaded, so passphrase prompts are no longer required per connection.
  • psql is local-only on my workstation (no local DB), so remote DB access must always be explicit (-h theServer / your host).
  • Found the key psql issue: Agent terminals were not automatically using the project-root .pgpass.
  • Fixed by placing credentials in the Windows location psql auto-reads:
    • copied F:\MyProject\.pgpass to %APPDATA%\postgresql\pgpass.conf

Result

Agent terminals now perform SSH and remote psql access the same way I do as the human operator.

Security note

This improves automation but reduces interactive control. In effect, agent-run commands can authenticate to remote infrastructure without manual approval each time. Use least-privilege accounts, locked-down host ACLs, and rotate keys/passwords regularly.

If anyone has a safer pattern (same reliability, tighter authorization), I’d love to compare approaches.

3

Hey, thanks for the detailed writeup. This is a solid reference for any user who runs into SSH or psql issues in agent terminals on Windows.

The core issue you hit, the agent terminal not inheriting the user environment the same way, is a known pain point. It can show up in different ways like PATH resolution, credential helpers, direnv, and more. Your approach of explicitly setting SSH precedence and placing pgpass.conf in the Windows standard location is the right call.

A couple of security notes since you asked:

  • For SSH key caching, note that ssh-add -c confirmation mode doesn’t work with the built-in Windows ssh-agent. It throws agent refused operation. If you want per-use confirmation on Windows, you’d need a third-party agent like Pageant. On Linux and macOS, ssh-add -c works fine and adds a useful prompt on each use without breaking automation entirely.
  • For psql, if your remote DB supports it, cert-based auth via clientcert=verify-full in pg_hba.conf can be cleaner than password-based .pgpass. This requires a separate client TLS certificate, not your SSH key, so it’s a bit more setup, but it’s worth it for sensitive environments.
  • Scope pgpass.conf entries to specific host, port, db, and user combos instead of wildcards. That limits the blast radius if the file is ever exposed.

If anyone has a tighter pattern, I’d also love to see it in this thread. Good stuff.

1 Like