VSCode’s SSH agent is bananas

Original Article ↗ Hacker News Discussion ↗

VSCode Remote SSH Architecture & Capabilities

  • VSCode’s “Remote - SSH” installs a substantial agent/server on the remote host (Node.js, many processes, persistent files).
  • The agent communicates with the local VSCode via port-forwarded WebSockets, and can browse the filesystem, edit files, spawn PTYs, and persist itself.
  • Crucially, Microsoft documents that a compromised remote can use this channel to execute code on the local machine; client and server are in the same trust boundary.
  • Several commenters note this is very different from a traditional SSH session, where the server cannot normally run arbitrary code on the client.

Security Concerns vs. “You Already Trust SSH”

  • Some argue there’s no new risk: if you can SSH and run arbitrary commands, you already have those powers; VSCode just automates it.
  • Others emphasize:
    • The agent is a long-lived, complex, partially closed-source service with a large attack surface.
    • It creates an unexpected reverse trust channel back into the client.
    • It leaves binaries and state behind, which is attractive for persistence and supply-chain attacks.
  • Comparisons are made to “curl | bash”: not inherently a bug, but a powerful pattern that normalizes risky behavior.

Comparison to TRAMP, sshfs, and Other Models

  • Emacs TRAMP and sshfs are held up as “living off the land”: no custom agent, just SSH/scp/sftp, and remote code stays on the server.
  • TRAMP/sshfs approaches are seen as safer but often slower, less featureful, and worse over high latency than VSCode/Zed-style smart remoting.
  • Some prefer explicit sync (rsync + watchexec) or tmux+vim/emacs on the server for predictability and simplicity.

Plugins, LLMs, and Capability Models

  • Unvetted extensions are a major concern: they get broad access locally and remotely, with no granular permission model.
  • VSCode’s “restricted mode” is seen as better than nothing but largely useless for real development because it disables most extensions.
  • There’s a long-standing request for per-extension capabilities (e.g., denying network/file access) with little visible progress.
  • LLM “agent” workflows that run and iterate on code automatically make these powers even more sensitive.

Microsoft Strategy, Openness, and Alternatives

  • Debate over whether VSCode is an “embrace, extend, extinguish” play:
    • Core is MIT-licensed, but key pieces (Remote SSH, Pylance, marketplace, some AI tooling) are proprietary or TOS-encumbered.
    • VSCodium and openvscode-server exist but can’t access all official extensions; some OSS reimplementations of remote exist.
  • Others counter that VSCode set a high bar, drove LSP adoption, and competitors had decades to improve.
  • Alternatives discussed: Eclipse Theia, JetBrains remote, Zed, Helix, Lapce (WASI plugins), Sublime, classic Vim/Emacs, sshfs-based workflows.

Real-World Impact & Admin Experiences

  • In teaching environments and multi-user servers, .vscode-server is blamed for:
    • Dozens of Node processes per user, heavy RAM/CPU usage, large disk footprints.
    • Students not learning basic SSH/CLI because VSCode hides it.
  • Some admins respond by killing VSCode server processes or banning its use; others say extra resources are trivial and the UX gains justify it.

Editor Culture & Pragmatism

  • Vim/Emacs users often see VSCode’s remote model as overcomplicated and fragile; VSCode users describe it as the first truly usable remote IDE.
  • Many commenters accept the risk: they run VSCode Remote only against dev VMs/containers, not production, and rely on isolation (VMs, Docker, bubblewrap) rather than trusting the IDE.