🔶 VSCode 的 SSH Agent 太离谱了（2025）

我们有兴趣接入 VSCode 用于通过 SSH 进行远程编辑的工作流，因为现在人人都在用 VSCode；尤其是，他们在使用那些通过 LLM 生成代码的 VSCode 分支。

当 LLM 把代码写错时，我们称之为“幻觉”；当人把代码写错时，我们称之为“工程”。

如果你知道自己在做什么，LLM 生成的代码在一般情况下是有用的。但如果你能打通 LLM 与执行环境之间的闭环（采用一种“Agent”设置），它就会变得格外有用。关于这件事可以说很多，但暂且这样理解：它是应对幻觉的一种半有效解药——LLM 生成代码，Agent 脚手架运行代码，代码产生错误，Agent 将错误反馈给 LLM，如此反复迭代。

因此，显而易见的问题是：你不希望这种迭代式开发过程发生在自己的开发笔记本上，因为 LLM 的边界感存在问题；它们会和迭代你当前正在处理的 Git 项目一样愉快地迭代你的系统配置。有一种能力你会非常希望拥有：在一个能即时启动、干净的 Linux 实例上，为 LLM 运行闭环的 Agent 式（“agentic”？现在是这么说的吗）配置，而且这个实例无论如何都无法坑到你。你知道我们要说什么了。

总之！我想提出一个担忧。

Emacs 承载着远程编辑系统的精神先驱：一团极其有用的 Elisp，名为 “Tramp”。只要你能将 Tramp 接入某种交互式环境——通常是一段 SSH 会话——并且该环境能够运行 Bourne Shell 命令，它就能将 Emacs 扩展到那个环境中。

所以，VSCode 也有一个类似 Tramp 的功能。很不错，对吧？你可能会以为：拿 Tramp，或许稍微简化一下，再把 Elisp 换成 TypeScript。

你想错了！

与依托远程连接既有环境运行的 Tramp 不同，VSCode 发起的是一场全面入侵：它运行一段 Bash 预备程序，下载一个 Agent，其中包括 Node 的二进制安装包。

我_认为_这就是源代码？

这个 Agent 通过端口转发的 SSH 运行。它会与正在运行的 VSCode 前端建立一条 WebSockets 连接。该连接底层协议能够：

• 在文件系统中四处游走
• 编辑任意文件
• 启动自己的 Shell PTY 进程
• 持久化自身

在安全领域，以这种方式工作的工具有一个名称。我不会把它说出口，因为这对 VSCode 不公平；但我们只需说，这个名字带有鼠类的意味。

我会对允许人们通过 VSCode 远程编辑开发服务器上的内容感到有些紧张；如果这种事发生在生产环境某项服务的事故处理中，我会暴跳如雷。

事实证明，要让 Fly Machine 的自定义连接在 VSCode 中运行，我们根本不需要关心这些事情，因此从更深层意义上说，这一切都无关紧要；但是：我们决定重新只做一个博客，所以：我们不得不弄清楚这些，现在你也得知道。

We’re interested in getting integrated into the flow VSCode uses to do remote editing over SSH, because everybody is using VSCode now, and, in particular, they’re using forks of VSCode that generate code with LLMs.

”hallucination” is what we call it when LLMs get code wrong; “engineering” is what we call it when people do.

LLM-generated code is useful in the general case if you know what you’re doing. But it’s ultra-useful if you can close the loop between the LLM and the execution environment (with an “Agent” setup). There’s lots to say about this, but for the moment: it’s a semi-effective antidote to hallucination: the LLM generates the code, the agent scaffolding runs the code, the code generates errors, the agent feeds it back to the LLM, the process iterates.

So, obviously, the issue here is you don’t want this iterative development process happening on your development laptop, because LLMs have boundary issues, and they’ll iterate on your system configuration just as happily on the Git project you happen to be working in. A thing you’d really like to be able to do: run a closed-loop agent-y (“agentic”? is that what we say now) configuration for an LLM, on a clean-slate Linux instance that spins up instantly and that can’t screw you over in any way. You get where we’re going with this.

Anyways! I would like to register a concern.

Emacs hosts the spiritual forebearer of remote editing systems, a blob of hyper-useful Elisp called “Tramp”. If you can hook Tramp up to any kind of interactive environment — usually, an SSH session — where it can run Bourne shell commands, it can extend Emacs to that environment.

So, VSCode has a feature like Tramp. Which, neat, right? You’d think, take Tramp, maybe simplify it a bit, switch out Elisp for Typescript.

You’d think wrong!

Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.

I think this is the source code?

The agent runs over port-forwarded SSH. It establishes a WebSockets connection back to your running VSCode front-end. The underlying protocol on that connection can:

• Wander around the filesystem
• Edit arbitrary files
• Launch its own shell PTY processes
• Persist itself

In security-world, there’s a name for tools that work this way. I won’t say it out loud, because that’s not fair to VSCode, but let’s just say the name is murid in nature.

I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.

It turns out we don’t have to care about any of this to get a custom connection to a Fly Machine working in VSCode, so none of this matters in any kind of deep way, but: we’ve decided to just be a blog again, so: we had to learn this, and now you do too.