VSCode's Remote SSH Agent: A Security Red Flag
Original: VSCode's SSH Agent Is Bananas (2025)
Why This Matters
As agentic coding workflows normalize remote execution, VSCode's invasive SSH model warrants broader scrutiny from security teams.
Fly.io engineer Thomas Ptacek details how VSCode's remote SSH feature works — downloading a full Node.js binary agent onto the remote host, establishing a WebSocket connection, and gaining broad filesystem and shell access. The post raises sharp security concerns for anyone using VSCode remote editing on dev or production servers.
Fly.io's Thomas Ptacek (@tqbf) set out to integrate Fly Machines into VSCode's remote editing workflow — motivated by the rise of LLM-driven 'agentic' coding setups like Cursor and Copilot Workspace, where closing the loop between code generation and execution requires a live remote environment. Along the way, he discovered just how invasive VSCode's Remote SSH extension actually is.
Unlike Emacs's 'Tramp' — which lives off the land over an SSH session, running basic Bourne shell commands on whatever the remote system already has — VSCode executes a Bash snippet that stages and downloads a full agent, including a bundled Node.js binary. That agent communicates back to the local VSCode front-end over a port-forwarded SSH tunnel using WebSockets.
The capabilities of that connection are extensive: filesystem traversal, arbitrary file editing, launching PTY shell processes, and persistence. Ptacek stops short of naming the security category this resembles ('murid in nature,' he hints), but the implication is clear. He flags this as a meaningful concern for anyone allowing VSCode remote access to dev servers — and a near-crisis scenario on production systems during an incident. For Fly.io's immediate use case, none of this ended up blocking their integration, but the post stands as a pointed technical disclosure.