VS Code Remote Development

why this matters for GPU work

Training and profiling code almost never runs on the machine you're typing on — it runs on a server with the GPUs. Without remote development, that means editing on a laptop, then scp/rsync-ing files over, or editing directly with a terminal-only tool over SSH. VS Code's Remote-SSH extension instead runs a small server-side agent on the remote host and gives you the full local-feeling editor — IntelliSense, the debugger, extensions — operating on files and processes that live entirely on that remote machine.

remote - ssh

Install the Remote - SSH extension (see VS Code Extensions), then connect to any host you can already reach with plain ssh — it reuses your existing SSH config and keys automatically.

ctrl+shift+p → Remote-SSH: Connect to Host | https://code.visualstudio.com/docs/remote/ssh | connects to any host listed in ~/.ssh/config, or one typed as user@host |'vrm_ssh1'

Once connected, the entire window — file explorer, terminal, extensions, debugger — operates against the remote filesystem and processes. The status bar's leftmost green segment always shows which host (or "local") the current window is attached to.

wsl (windows subsystem for linux)

Same underlying idea as Remote-SSH, but the "remote" target is a Linux environment running alongside Windows on the same machine — useful when tooling (CUDA, most ML frameworks) assumes Linux, but the laptop is Windows.

ctrl+shift+p → WSL: Connect to WSL | https://code.visualstudio.com/docs/remote/wsl | reopens the current window against the WSL filesystem instead of Windows |'vrm_wsl1'

dev containers

A step further than either of the above: the repo itself defines its exact development environment in a .devcontainer/devcontainer.json file (base image, extensions, environment variables). Anyone who opens the folder gets an identical environment, built by Docker — no more "works on my machine."

ctrl+shift+p → Dev Containers: Reopen in Container | https://code.visualstudio.com/docs/devcontainers/containers | rebuilds (or reuses) the container defined for this repo, then reconnects VS Code to it |'vrm_dc1'


{
  "name": "cuda-dev",
  "image": "nvcr.io/nvidia/pytorch:24.05-py3",
  "runArgs": ["--gpus", "all"],
  "customizations": {
    "vscode": { "extensions": ["ms-python.python", "ms-vscode.cpptools"] }
  }
}

keeping remote work alive

A Remote-SSH connection dying doesn't kill whatever it was running remotely, but the integrated terminal's shell session itself won't survive a dropped connection unless something keeps it alive independently. Run long training jobs inside a tmux session on the remote host — the job keeps running (and stays reattachable) regardless of what VS Code's connection does.

forwarding ports

Remote-SSH auto-detects and forwards ports a remote process opens — so jupyter notebook or tensorboard --logdir runs/ running on the GPU server shows up as a normal localhost URL in your local browser, no manual SSH tunnel (ssh -L ...) required.

reference

code.visualstudio.com — remote development overview
code.visualstudio.com — Remote-SSH
containers.dev — Dev Container spec