I think the actual concern, not well expressed in the blog post, is the fact that node and vscode server are installed on, for instance, a prod machine that (probably) should be very tightly controlled in terms of what software is installed and running. You don't want to unwittingly add to the attack surface

▲

pstuart 2 hours ago | parent [-]

Fair enough, but running VSCode on a prod machine is also bananas.

▲

Vegenoid 2 hours ago | parent | next [-]

Yes, and now we are full circle: what is (allegedly) bananas is that using VSCode’s remote edit feature has the potentially surprising and unintuitive behavior of installing a VSCode agent on the target machine.

	▲	__float 19 minutes ago \| parent [-]
		It didn't occur to me when I first read the article, but I do see now the author called it "remote editing" as you did too. It may be worth more attention though. VSCode is not really remote editing (thick client, thin server binary), it's setting up a development environment (compilers, LSPs, editor extensions, etc.) on a remote thing (VM, container) that you access with a thin VSCode shell. If you want to quickly edit a config file on a remote machine, TRAMP seems great. VSCode Remote SSH is not meant for that.

▲

Banditoz 2 hours ago | parent | prev | next [-]

The assumption being made is VSCode is not running on the prod machine.

▲

K0IN 2 hours ago | parent | prev [-]

agree, but do you think every dev you know konws this?

also "i just want to edit a config file and i want a nice ui", is how you get there.

	▲	doc_ick 2 hours ago \| parent [-]
		Expecting vscode to police every single dev using it instead of a company is bananas.