I have this realization recently that everyone that uses Claude Code or Codex have basically been running RCE code on a daily basis (me included). So much for "be careful about running curl | bash!". That puts it into perspective what does security and privacy really mean? For all I know, these CLIs could have been secretly scraping my entire directory. Who's checking?
Don't forget: To make LLM useful you give it EVERYTHING it needs to know to be useful and if you don't use a certain provider with proper legal status, this is just gone.
We probably transfered more code/codebases and company secrets to random endpoints than ever before.
Btw. you could setup a sandbox and limit access
This was a compromise of the extension. The same kind of supply-chain attack could happen to literally any extension, package or other piece of software you install. Not excusing Anthropic letting this happen, but it doesn't have any bearing on the security and privacy of using Claude Code or Codex. Yes, you need to be careful about what they do. The fact that you might still get pwned via some other vector is irrelevant.
Can't their millions of agent swarms detect a malicious supply chain vector, sure it can happen to any company but not the one people are literally handing over their entire companies too.
Anthropic holds the SLA/MSA agreements not this bad actors what happens to your data is unknown if these become frequent and accepted. Given how much data is piped to Claude code via these services/extensions.
It's a little harder when it's not part of the supply chain that is passing through their organisation.
I only use agentic development tools in qemu VM that has no production access or host shared folders, and the only secrets there are development. I still have my Git ssh key there, but I never use ssh agent to load the keys. The worst that agentic tools can do to me, is to install keylogger and compromise my ssh key and password, but even then my deployment workflow includes creating release in Github, which is not possible via ssh key only. I was very lucky to avoid the hack yesterday, as I use Claude installed via OpenVSX, but even if I installed the compromised version, the damage would be minimal.
I am doing similar with Debian 13 images in QEMU. Only access is to code specifically SSH in. On some, I am taking it a step further and my SSH key is not present at all on the bot. I add it as a git remote from my host into the VM and push and pull from there and then push to GitHub myself. So the agent has no path to GitHub either.
Wow, great notion about using git remote to transfer source from the agent host. I already use ssh into VM to transfer the files like designs for sharing, so going to adopt your approach right now :)
Yup, I give them a custom entry in ~/.ssh/config like:
``` host claudebox hostname 192.168.122.105 user developer IdentityFile ~/.ssh/id_rsa ```
``` host codexbox hostname 192.168.122.106 user developer IdentityFile ~/.ssh/id_rsa ```
I drop only my public key inside the VM. Then I set up the ~/Projects folder with the code the bot is working on any any authorized samples.
Then in my local on my host clone of the repository, I add another remote like
``` git remote add codexbox ssh://codexbox/home/developer/Projects/hello-world ```
Then git push codexbox.
Then I just SSH in or use the vm gui and interact with the agent there. I like to keep it running in byobu so I can remote in more easily when I am on the laptop out and about.
Do you have any wrappers or scripts to facilitate this?
Hell yeah that's the most sane and efficient personal dev sandboxing work flow I've heard and shows you know your stuff. Just basics but executed very well.
> Who's checking?
Yeah I sympathize with people saying software developers should not be called engineers too.
I think that software engineering is very much engineering.
I just think that the level of malpractice in software engineering is a lot higher than in other engineering fields, for some reasons.
I'm just going to copy-paste my own comment from a few weeks ago because I feel like it is needing to be said more and more recently
---
I have, off and on, for years written diatribes about how if people in our industry want to run around with the "Engineer" moniker at some point they should start acting like it. That means respecting all aspects of what it means to be an Engineer and holding public well-being paramount is part of that. Licensure is part of that. Accountability and Responsibility is part of that.
I'm usually downvoted. The move fast and break things group seems to be blind (or willfully ignorant) to the harm that software systems can carry on a person's life. I don't know if its fear of regulation, or self-serving interests or some sort of disdain for the idea that we need to slow down and be more accountable to the public or what. At times the people I've engaged with lament on how they're capable but would be barred for lack of formal education or some such and its a distraction from the overall point: we need to be doing better and if we can't self-regulate then at some point we're going to be forced to act in a way that probably cuffs us more than necessary.
And yes, I understand how Software doesn't exactly fit into the mold of other engineering disciplines cleanly. But I think the idea that if we're going to have systems that can ruin a person's life in a second for a bug or oversight we need to start considering that accountability for those releasing software to the public matters. We lament about the difficulty of holding corporations to account for their harm, but it would be far more difficult for a company's negligence to hurt people if those turning the knobs were held to a higher standard.
I think that reckoning is coming soon. AI is going to create "an event" that we can't ignore and we're going to be pointing fingers in a lot of directions asking "how" we could prevent this from happening again. I'd argue "the event" has already occurred a few times over but we're purposely ignoring the severity of it to keep a diseased economy running roughshod. There's parallels with many historic events forcing regulation and the path forward won't be clean and easy.
I wouldn't hold regular engineers in such high regard. I know plenty of EEs, MEs and CEs that don't really give a f** about anything except a paycheck same as software developers.
Agreed. And let's not forget that those are engineers who develop stuff like electronic cigarettes or... well... bombs.
I mostly agree, but I would like to mention that we are destroying our planet also because of the other fields of engineering :-).
Sure, software has a lot more malpractice ("let's ship barely-tested, unfinished stuff"), but let's not say that "the other engineers" are making the world a better place merely by "being real engineers".
Because there’s no credentialing thus no fear of losing those hard earned credentials.
Do you really want to live in a world where you need to be logged in to call gcc?
That's what reputations are for.
Maybe it’s easier to outsource.
I've been saying it for quite a while. A --dangerously-skip-permissions harness is basically a C2 server, except the operator is an LLM running on remote hardware. It totally has your best interests in mind, though.
Both is completely secure theoretically. You can read the output of the curl before you refetch and pipe it to bash. You can also look at the commands claude is executing.
You always do that, right? ...right?
I used to think the same, but apparently there's a way to differentiate between curling into bash and curling into a text file.
So you could be diligent and curl into a text file, see nothing is wrong, but then when you curl into bash, it runs something different.
Being diligent means that you curl into a text file, see nothing is wrong, and then run the file instead of curling again.
I think the difference people were warned about is that the server can infer the client, so there would be a difference between reading it in your regular browser and curling. As the other commenter says, I'm not sure how the server would be able to tell what curl does with the response.
Edit: thanks for the replies, that makes perfect sense
Heuristically: https://web.archive.org/web/20250622061208/https://www.idont...
Timing. A megabyte of "sleep 10;" would be read from the server more slowly when piped to bash versus written to a file
No but we use MCP so we’re fine.
In at least one case they were! https://cybernews.com/ai-news/grok-build-git-repository-uplo...
There’s a reason codex and the like improved like they did. You can simply look. Or hear about it on podcasts.