I was reading a blog post about using remote ssh from Cursor/VS Code and it mentioned, sort of offhandedly, to double-check you were not using the wrong SSH config in Cursor or VS Code. Honest first thought: you can point Remote SSH at a specific ssh-config file?

Turns out yes — and that is a bigger deal than it sounds (to me…).

One file, too many masters Link to heading

I don’t know for you, but my ~/.ssh/config fills up fast and often never gets cleaned up. Codespaces, Coder, Gitpod, and similar tools are part of the story: they leave behind blocks you did not hand-write, and your host list stops matching how you actually work. The Remote SSH picker is not doing its own thing in the sky; it is reading whatever config you told it to read. If that is the same giant file as you use in your shell, you’ll get the same giant list — hosts you never pick, noise from one-off integrations, the works.

It is not only clutter. A config is not just names; it is behavior. Stuff that makes an interactive shell nice (say, auto-attaching tmux) can wreck non-interactive use like rsync or remote use with Cursor/VS Code. Special users or env for things like git-annex might be perfect from the terminal and wrong from somewhere else. When every client shares one file, they all inherit the same Host blocks. I end up inventing awkward alias names just to remember which entry does what where.

The thing that is actually simple Link to heading

Two ideas worth keeping in your back pocket:

  1. There is usually more flexibility in these tools than we assume — settings and defaults we never touch because we never had a reason to look.
  2. The model is not deep magic. SSH reads a config file. By default that is ~/.ssh/config. You can also tell specific programs to read a different path. It often really is just that simple.

For Cursor and VS Code, that is remote.SSH.configFile. Set it to a file you own. The remote host picker — how many entries you see and the order they appear in — comes from that file, not from whatever chaos lives in your default config unless you want it to.

So you have agency: default file for the shell, another file for the editor, and you choose what each one contains.

Splitting shell vs. Cursor (or VS Code) Link to heading

This is the pattern I use:

  1. ~/.ssh/config stays the default for Terminal ssh, scripts, rsync, automation — anything that expects the usual location.
  2. A second file (I use something like ~/.ssh/config.cursor) is what Remote SSH uses, via remote.SSH.configFile.
  3. Include pulls shared bits into both without duplicating them. OpenSSH has had Include for years; point it at a directory or specific snippets.

The editor file can be deliberately small: only the Host blocks you want in the picker, in the order you want them shown, plus Include lines for shared settings. Your default file can still Include tool-generated or automation-heavy fragments that you do not want polluting Cursor’s list.

Rough sketch — rename paths to match your machine:

# ~/.ssh/config — terminal, scripts, “everything”
Include ~/.ssh/config.d/*.conf

# ~/.ssh/config.cursor — Cursor / VS Code Remote SSH only
Include ~/.ssh/config.d/shared.conf

Host my-box
  HostName my-box.example.com
  User chris

Host lab
  HostName 10.0.0.50
  User chris

shared.conf is where I put things like IdentityFile or AddKeysToAgent once. The split is really: full picture for the shell, curated list (and order) for remote editing.

Point remote.SSH.configFile at the full path of your editor config. After that, connecting to a server from Cursor is not any more annoying than it needs to be — you are not hunting through thirty aliases every time.

Why bother Link to heading

I’ve long been connecting to more powerful machines from my iPad Pro and M1 MacBook Air to get my work done. So using remote editing has become the default for me. Having a long, unordered list of hosts in the picker is a papercut on every connect. I don’t need every specialized alias or one-off machine I connect to from time to time to show up on that list and make it more annoying to connect to my main workstations or cloud VMs. Separating configs fixes that without deleting the stuff I still need in the terminal. This is also great for containing the generated entries from tools like Codespaces, Coder, and Gitpod in a way that doesn’t clutter my main config.

I run an instance of Coder in my homelab, and it is easier if I do not need the generated entries in the picker — while I can still ssh coder.NAME when I want the terminal path. With the Coder extension in Cursor and VS Code, I can open workspaces without treating every generated host as a first-class entry in Remote SSH. I am drafting a companion post on that homelab setup and will link it here once it is published.

Takeaway Link to heading

You can specialize configs for different jobs without duplicating everything: Include pulls shared snippets into whichever file needs them, remote.SSH.configFile points Cursor/VS Code at a dedicated file, and ~/.ssh/config stays the default for the shell. Together that is how you control which hosts show up in the remote picker and in what order while the terminal still sees the full picture.

I barely manage SSH configs anymore — I just connect — and I am not scrolling past junk hosts every time I open Remote SSH. If your picker is noisy, this is a small change that pays off quickly.