Comment by anon-3988
1 day ago
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 :)
2 replies →
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.
3 replies →
Because there’s no credentialing thus no fear of losing those hard earned credentials.
2 replies →
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.
(Also, how in the world would a server be able to tell where you’re piping the response?)
Edit: thanks for the replies, that makes perfect sense
2 replies →
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.