In dit artikel analyseert Thomas Ptacek de werking van de remote editing-functionaliteit van VSCode via SSH. Hij vergelijkt dit met 'Tramp' uit Emacs; terwijl Tramp gebruikmaakt van bestaande middelen op de remote verbinding, installeert VSCode een volledige agent (inclusief Node.js) op de doelserver.
De auteur wijst erop dat deze agent via een WebSocket-verbinding uitgebreide bevoegdheden krijgt, zoals het bewerken van willekeurige bestanden, het doorzoeken van het bestandssysteem en het starten van shell-processen. Vanwege dit gedrag, dat volgens Ptacek doet denken aan malware, adviseert hij voorzichtigheid bij het gebruik van VSCode op development- en productieservers.
De SSH-agent van VSCode is krankzinnig
We zijn geïnteresseerd in integratie in de workflow die VSCode gebruikt voor remote editing via SSH, omdat tegenwoordig iedereen VSCode gebruikt, en in het bijzonder forks van VSCode die code genereren met LLM's.
"Hallucinatie" is wat we noemen wanneer LLM's code fout hebben; "engineering" is wat we noemen wanneer mensen dat doen.
LLM-gegenereerde code is in het algemene geval nuttig als je weet wat je doet. Maar het is extreem nuttig als je de lus kunt sluiten tussen de LLM en de execution environment (met een "Agent"-opstelling). Er valt veel over te zeggen, maar voor nu: het is een semi-effectief tegengif voor hallucinaties: de LLM genereert de code, de agent-scaffolding voert de code uit, de code genereert fouten, de agent geeft dit terug aan de LLM, en het proces herhaalt zich.
Dus, overduidelijk is het probleem hier dat je dit iteratieve ontwikkelingsproces niet op je eigen development-laptop wilt laten gebeuren, omdat LLM's moeite hebben met grenzen; ze zullen net zo vrolijk itereren op je systeemconfiguratie als op het Git-project waaraan je toevallig werkt. Iets wat je echt zou willen kunnen doen: een closed-loop agent-achtige ("agentic"? is dat hoe we het nu noemen) configuratie voor een LLM draaien op een schone Linux-instantie die direct opstart en je op geen enkele manier kan dwarsbomen. Je begrijpt waar we heen gaan.
Hoe dan ook! Ik zou graag een zorg willen uiten.
Emacs herbergt de spirituele voorvader van remote editing-systemen: een brok hypernuttige Elisp genaamd "Tramp". Als je Tramp kunt koppelen aan een willekeurige interactieve omgeving — meestal een SSH-sessie — waarin het Bourne shell-commando's kan uitvoeren, kan het Emacs uitbreiden naar die omgeving.
Dus, VSCode heeft een functie die lijkt op Tramp. Wat leuk, toch? Je zou denken: neem Tramp, vereenvoudig het misschien een beetje, en vervang Elisp door Typescript.
Fout gedacht!
In tegenstelling tot Tramp, dat gebruikmaakt van de aanwezige middelen op de remote verbinding, voert VSCode een grootschalige invasie uit: het draait een Bash-snippet stager die een agent downloadt, inclusief een binaire installatie van Node.
Ik denk dat dit de broncode is?
De agent draait over port-forwarded SSH. Het vestigt een WebSockets-verbinding terug naar je actieve VSCode front-end. Het onderliggende protocol op die verbinding kan:
- Ronddwalen in het bestandssysteem
- Willekeurige bestanden bewerken
- Eigen shell PTY-processen starten
- Zichzelf in stand houden (persist)
In de wereld van security is er een naam voor tools die op deze manier werken. Ik zal het niet hardop zeggen, want dat is niet eerlijk tegenover VSCode, maar laten we gewoon zeggen dat de naam van murid-aard is.
Ik zou een beetje nerveus zijn als ik mensen dingen liet remote-editten met VSCode op dev-servers, en apoplektisch als dat zou gebeuren tijdens een incident op een productiesysteem.
Het blijkt dat we hier helemaal geen zorgen over hoeven te maken om een custom verbinding met een Fly Machine werkend te krijgen in VSCode, dus in die zin doet dit er niet echt toe, maar: we hebben besloten om gewoon weer een blog te zijn, dus: wij moesten dit leren, en nu jij ook.
De SSH-agent van VSCode is krankzinnig
We zijn geïnteresseerd in integratie in de workflow die VSCode gebruikt voor remote editing via SSH, omdat tegenwoordig iedereen VSCode gebruikt, en in het bijzonder forks van VSCode die code genereren met LLM's.
"Hallucinatie" is wat we noemen wanneer LLM's code fout hebben; "engineering" is wat we noemen wanneer mensen dat doen.
LLM-gegenereerde code is in het algemene geval nuttig als je weet wat je doet. Maar het is extreem nuttig als je de lus kunt sluiten tussen de LLM en de execution environment (met een "Agent"-opstelling). Er valt veel over te zeggen, maar voor nu: het is een semi-effectief tegengif voor hallucinaties: de LLM genereert de code, de agent-scaffolding voert de code uit, de code genereert fouten, de agent geeft dit terug aan de LLM, en het proces herhaalt zich.
Dus, overduidelijk is het probleem hier dat je dit iteratieve ontwikkelingsproces niet op je eigen development-laptop wilt laten gebeuren, omdat LLM's moeite hebben met grenzen; ze zullen net zo vrolijk itereren op je systeemconfiguratie als op het Git-project waaraan je toevallig werkt. Iets wat je echt zou willen kunnen doen: een closed-loop agent-achtige ("agentic"? is dat hoe we het nu noemen) configuratie voor een LLM draaien op een schone Linux-instantie die direct opstart en je op geen enkele manier kan dwarsbomen. Je begrijpt waar we heen gaan.
Hoe dan ook! Ik zou graag een zorg willen uiten.
Emacs herbergt de spirituele voorvader van remote editing-systemen: een brok hypernuttige Elisp genaamd "Tramp". Als je Tramp kunt koppelen aan een willekeurige interactieve omgeving — meestal een SSH-sessie — waarin het Bourne shell-commando's kan uitvoeren, kan het Emacs uitbreiden naar die omgeving.
Dus, VSCode heeft een functie die lijkt op Tramp. Wat leuk, toch? Je zou denken: neem Tramp, vereenvoudig het misschien een beetje, en vervang Elisp door Typescript.
Fout gedacht!
In tegenstelling tot Tramp, dat gebruikmaakt van de aanwezige middelen op de remote verbinding, voert VSCode een grootschalige invasie uit: het draait een Bash-snippet stager die een agent downloadt, inclusief een binaire installatie van Node.
Ik denk dat dit de broncode is?
De agent draait over port-forwarded SSH. Het vestigt een WebSockets-verbinding terug naar je actieve VSCode front-end. Het onderliggende protocol op die verbinding kan:
- Ronddwalen in het bestandssysteem
- Willekeurige bestanden bewerken
- Eigen shell PTY-processen starten
- Zichzelf in stand houden (persist)
In de wereld van security is er een naam voor tools die op deze manier werken. Ik zal het niet hardop zeggen, want dat is niet eerlijk tegenover VSCode, maar laten we gewoon zeggen dat de naam van murid-aard is.
Ik zou een beetje nerveus zijn als ik mensen dingen liet remote-editten met VSCode op dev-servers, en apoplektisch als dat zou gebeuren tijdens een incident op een productiesysteem.
Het blijkt dat we hier helemaal geen zorgen over hoeven te maken om een custom verbinding met een Fly Machine werkend te krijgen in VSCode, dus in die zin doet dit er niet echt toe, maar: we hebben besloten om gewoon weer een blog te zijn, dus: wij moesten dit leren, en nu jij ook.
Groetjes,