Do you have credentials anywhere within reach of that session? Can you open your bank account in a browser ... within reach of that session? Are your contacts available within reach of that session? What about personal notes/emails/goals or other sensitive information? That people think these can't be added together in one very socially/monetarily destructive fell swoop is ... telling.
Ignoring obvious bad-actor concerns from just giving root to your whole life to an LLM running on someone else's server, LLMs themselves can act in ways that are extremely counterproductive to their organization/host/etc.
A quote/warning I learned in the late 90s is just as relevant today, "Computers make very fast, very accurate mistakes."
Anything an LLM does on your computer should happen it its own account. No sudo config of course, or at most one that is strictly limited to what you want to allow it to do (risk here, as many programs have non-obvious paths to general command execution).
It should have zero access to your private home directory or your system configs. You can have access to its files of course. That's the beauty of separate accounts and permissions.
How many devs really do run damned near everything from a single account that also has sudo/runas/various_osx_methods access? This threat model has a decidedly non-zero target market.
Even those folks who are cautious enough to require passwords (sudo or plain su) to elevate are still at risk of having their account thoroughly brought under control of an attacker. Just imagine what a baddie could inject into your .bashrc if your editor can change it.
If you run your clanker-controlled emacs in console mode under a restricted user account, best case scenario, system compromise is only one unpatched privesc vuln away from Shai-Hulud completely pwning you.
Doing it in a locked down VM is much better but even then you're only better off by matter of degrees than if you had done a yolo curl - | bash because VM host attacks and even escapes are very much a thing.
These HNers expressing concern about giving a LLM control of an editor are 100% thinking rightly.
This is a textbook motte-and-bailey. You're telescoping threat escalation - chaining together "what if" steps until everything sounds equally catastrophic:
"Your editor can write to .bashrc. Therefore an attacker controls your shell. You probably have sudo. Therefore full system compromise. Even a VM does not help because VM escapes exist. Therefore this is basically curl|bash."
By this reasoning, every program you run under your user account is equally dangerous. Your shell, your file manager, git, make, pip install, npm install, docker, any program that writes files. The argument proves too much, therefore proves nothing.
This is all unhinged poetry - philosophical argy-bargy without any concrete, well-grounded argumentation. I'm just baffled for why none of you guys crying wolf even tried to ask me reasonably productive questions of what do I actually do in my setup.
- My LLM use is mainly not about code generation. Especially it is not about autonomous code generation and execution.
- Why nobody's asking about scope of the LLM file access, audit logs, tool use confirmation, allowlists/denylists, rate limiting/circuit breakers - pre-tool hooks, scoped tool sets per context, etc.?
Whatever. If you think it's unsafe - just don't do what I'm doing. Just please spare me from security-as-ritual, I don't believe in prayers, I preach security-as-engineering. None of you proposed a threat model. None of you started with: "here is the specific attack, here is the attack vector, here is the probability, here is the blast radius", it's all just: "imagine what a baddie could do" followed by an escalation chain that terminates in total system compromise. By that reasoning you should not run any software.
In the interconnected, online world, you can do more damage without root access
"they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission"
https://xkcd.com/1200/
So? My terminal has the same full system access. If I didn't use Emacs, I'd be using Claude code in it. It's contained locally on my computer, I don't see any problem here. I use Emacs like my OS-layer. Why would I complain that my OS has access to something? It would be weird and annoying if it's the opposite.
Yeah, that's incredibly unsafe. You made a footgun machine and you're firing it with no shoes on. Don't run that on any machine with credentials you care about.
At the very least, run it in Docker. It's not a security tool, but it's at least some kind of guardrail against data loss and exfiltration.
Having a browser on your machines is unsafe. The browser is a massively more dangerous attack surface than an Emacs-based LLM tool. What I have is a curated set of Lisp functions exposed to an LLM through a protocol I control, running in a single-user process, on my machine, behind my firewall. The attack surface is comically small by comparison.
Any browser that I trust to not instantly[1] eat my face has sandboxing features to at least pretend it wants to be secure. I'm not aware of any text editor that has built in anything of the sort.
It's a nice habit to get into if you can bring yourself to firejail your editor to $HOME/jail and keep all your r/w files in $HOME/jail/Documents and such. But only the most socially unacceptable of paranoid sysadmins do that. Ahem.
[1] FF/Chrome/javascriptless ones. The others are put in prison with no chance of parole and strict visitation policies.
A browser's sandbox exists because it routinely executes arbitrary code from untrusted remote origins. Emacs (or any other editor) with an LLM integration does not fetch and auto-execute code from random origins. Your firejail point proves too much, even though the idea sure is riveting. By that logic, my shell is also catastrophically insecure - it can rm -rf /, read my ssh keys, send some files anywhere. Yet nobody seriously argues shells need browser-style sandboxing. The implicit trust model is different: these are tools where you control what runs.
Yes, there are prompt injection risks, they are legit but that's the property of the LLM, not Emacs. A browser sandbox protects you from code you never chose to run. An editor integration runs code you asked for. These are different problems requiring different mitigations.
You guys keep patronizing me on this, you think I'm some truck driver/florist/butcher by day, and I put on my amateur coder suit at night? Just so you know, I spent years working on security.cisco.com team and went through SANS training and certification. Ever occurred to you that just maybe, perhaps, potentially, theoretically, hypothetically - I'm not completely, utterly ignorant about all this shit?
I don't think it's very reasonable to use claude code on a computer that have credentials without some kind of sandboxing or validing every command it does, at which point I'd rather do things manually
Ah come on, guys, let's talk pragmatically. "Malleable editor as an OS layer" has benefits beyond subjective reasoning. Emacs has had M-x shell-command and arbitrary elisp eval forever. A metacircular MCP isn't some new capability class. Even if I didn't use Emacs - my shell, my editor, my browser extensions, my npm install, my VSCode plugins, my curl | bash from yesterday - they all have the same access. Singling out the LLM in this context is like selection bias.
Of course, reasonable mitigations are a must - just like for any other tool. Narrowing MCP scope - tool routing rules, read-only git defaults, etc. "Docker or nothing" is a lazy answer - Docker-for-everything has real costs: friction, broken integrations, worse ergonomics.
Practical security is all about staying in the goldilocks zone. You shouldn't get relaxed about the basics - sandboxing, 2FA, password managers - they are worth doing, and you can get so paranoid about so many things, and yet against a targeted, well-resourced attacker, your sandboxing posture is mostly irrelevant. The interesting attacks bypass the threat model entirely. Read about Ben Nassi's team research¹ - pretty cool example. There are multitudes of other ways and your Docker container won't stop them. Defend against the boring 99%, and accept that the 1% is someone else's problem (or a much bigger problem than your dev environment)
TLDR LLM Summary: Researchers showed that a device's power LED subtly flickers in brightness and color while the CPU performs cryptographic work, and these flickers leak information about the secret key. By pointing an ordinary video camera (an iPhone or an internet-connected security camera) at the LED and exploiting the camera's rolling shutter, they boosted the effective sampling rate from 60 to 60,000 measurements per second, enough to do cryptanalysis. Using only this video footage, they recovered full ECDSA and SIKE keys from a smartcard reader and a Samsung Galaxy S8, with no malware on the target devices.
It's your computer and you can do whatever yolo nonsense you want, my dude, but put those goalposts back where they were.
"Don't run that shit on a credentialed box with data you care about" is addressing real threats, not some goofy nation state thing or abstract security research.
If you let the footgun machine constantly generate new code and run it on your computer, you're just asking for data loss and bad shit to happen.
Docker isn't a great solution but it at least doesn't let yolo code delete files or access env vars or read the contents of .ssh/
> my browser extensions, my npm install, my VSCode plugins, my curl | bash
Yeah, and you shouldn't yolo those, either lol. If they didn't come from a trusted source, you need to read through them. If you don't want to, don't use them. That's not paranoia, that's, like, normal.
> If you let the footgun machine constantly generate new code
Are you talking about autonomous LLM projects that automatically write code? Yeah, no shit, I wouldn't run anything like that directly on any machine without sandboxing. My typical LLM use inside my editor is never in self-driving mode, there's not even cruise-control - I tell it exactly when to write, where to write and how to do it. Automated scripts never get run by LLM and don't get to run at all without prior precise and meticulous inspection. I'm not moving goalposts - at worst we're in disagreement on the level of pragmatics vs. paranoia, that's all.
I don't even get why people are so crazy about LLMs generating code - on both sides. LLMs for me personally are such a great tool for investigating things, for finding things, for bridging the gaps - the stuff that happens 10K feet above code writing. By the time I'm done gathering the details, code generation becomes an almost insignificant touch of the whole endeavor.
That exactly what it is. People's reaction is a default pattern-matching on "AI executes code on your machine." - Ay the horrors!. They have no idea of my cybersec posture, my network perimeter - vpn, firewall, malware protection, etc.
It's not like I'm giving the LLM root shell. It's as if I said: "I learned how to juggle three chainsaws - so fun...", and people reacted as if I suggested doing that in a school bus full of children going 140kmh down the highway.
It's culturally fitting for HN - signaling caution is always socially safe. Nobody ever got criticized for saying "that sounds risky". But "I evaluated the risks and accepted the tradeoffs for my situation" is the actual, pragmatic engineering. Security is risk management, not risk elimination.
Do you have credentials anywhere within reach of that session? Can you open your bank account in a browser ... within reach of that session? Are your contacts available within reach of that session? What about personal notes/emails/goals or other sensitive information? That people think these can't be added together in one very socially/monetarily destructive fell swoop is ... telling.
Ignoring obvious bad-actor concerns from just giving root to your whole life to an LLM running on someone else's server, LLMs themselves can act in ways that are extremely counterproductive to their organization/host/etc.
A quote/warning I learned in the late 90s is just as relevant today, "Computers make very fast, very accurate mistakes."