That directory has a bunch of of sensitive stuff in it, most notable the transcripts of all of your previous Claude Code sessions.
You may want to take steps to avoid a malicious prompt injection stealing those, since they might contain sensitive data.
theden 48 minutes ago [-]
Kinda funny that a lot of devs accepted that LLMs are basically doing RCE on their machines, but instead of halting from using `--dangerously-skip-permissions` or similar bad ideas, we're finding workarounds to convince ourselves it's not that bad
simonw 33 minutes ago [-]
Because we've judged it to be worth it!
YOLO mode is so much more useful that it feels like using a different product.
If you understand the risks and how to limit the secrets and files available to the agent - API keys only to dedicated staging environments for example - they can be safe enough.
croes 2 minutes ago [-]
> Because we've judged it to be worth it!
Famous last words
zahlman 27 minutes ago [-]
Why not just demand agents that don't expose the dangerous tools in the first place? Like, have them directly provide functionality (and clearly consider what's secure, sanitize any paths in the tool use request, etc.) instead of punting to Bash?
TeMPOraL 9 minutes ago [-]
Because it's impossible for fundamental reasons, period. You can't "sanitize" inputs and outputs of a fully general-purpose tool, which an LLM is, any more than you can "sanitize" inputs and outputs of people - not in a perfect sense you seem to be expecting here. There is no grammar you can restrict LLMs to; for a system like this, the semantics are total and open-ended. It's what makes them work.
It doesn't mean we can't try, but one has to understand the nature of the problem. Prompt injection isn't like SQL injection, it's like a phishing attack - you can largely defend against it, but never fully, and at some point the costs of extra protection outweigh the gain.
simonw 22 minutes ago [-]
Because if you give an agent Bash it can do anything they can be achieved by running commands in Bash, which is almost anything.
VTimofeenko 10 minutes ago [-]
Tools may become dangerous due to a combination of flags. `ln -sf /dev/null /my-file` will make that file empty (not really, but that's beside the point).
cindyllm 24 minutes ago [-]
[dead]
pjm331 14 minutes ago [-]
I feel like you can get 80% of the benefits and none of the risks with just accept edits mode and some whitelisted bash commands for running tests, etc.
catlifeonmars 20 minutes ago [-]
Shouldn’t companies like Anthropic be on the hook for creating tools that default to running YOLO mode securely? Why is it up to 3rd parties to add safety to their products?
catlifeonmars 21 minutes ago [-]
People really really want to juggle chainsaws, so have to keep coming up with thicker and thicker gloves.
If you don't mind a suid program, "firejail --private" is a lot less to type and seems to work extremely similarly. By default it will delete anything created in the newly-empty home folder on exit, unless you instead use --private=somedir to save it there instead.
typs 1 hours ago [-]
I wish I had the opposite of this. It’s a race trying to come up with new ways to have Cursor edit and set my env files past all their blocking techniques!
GrowingSideways 1 hours ago [-]
If you wouldn't upload keys to github, why would you trust them to cursor?
hahahahhaah 57 minutes ago [-]
A local .env should be safe to put on your T shirt and walk down times square.
Mysql user: test
Password: mypass123
Host: localhost
...
Imustaskforhelp 56 minutes ago [-]
Create a symlink to .env from another file and ask cursor to refer it if name is the concern regarding cursor (I don't knowhow cursor does this stuff)
meander_water 41 minutes ago [-]
I recently created a throwaway API key for cloudflare and asked a cursor cloud agent to deploy some infra using it, but it responded with this:
> I can’t take that token and run Cloudflare provisioning on your behalf, even if it’s “only” set as an env var (it’s still a secret credential and you’ve shared it in chat). Please revoke/rotate it immediately in Cloudflare.
So clearly they've put some sort of prompt guard in place. I wonder how easy it would be to circumvent it.
catlifeonmars 33 minutes ago [-]
May I suggest rm -f .env? Or chmod 0600 .env? You’re not running CC as your own user, right? …Right?
Oh, never mind:
> You want to run a binary that will execute under your account’s permissions
dangoodmanUT 44 minutes ago [-]
I've been saying bubblewrap is an amazing solution for years (and sandbox-exec as a mac alternative). This is the only way i run agents on systems i care about
catlifeonmars 24 minutes ago [-]
> run agents on systems i care about
You must not care about those systems that much.
Nora23 1 hours ago [-]
Smart approach to AI agent security. The balance between convenience and protection is tricky.
gexla 35 minutes ago [-]
I believe this is also what Claude Code uses for the sandbox option.
isodev 49 minutes ago [-]
My way of preventing agents from accessing my .env files is not to use agents anywhere near files with secrets. Also, maybe people forget you’re not supposed to leave actual secrets lingering on your development system.
Had this same idea in my head. Glad someone done it. For me the motivation is not LLMs but to have something as convenient as docker without waiting for image builds. A fast docker for running a bunch of services locally where perfect isolation and imaging doesnt matter.
JCattheATM 58 minutes ago [-]
So, Flatpak?
Funny enough Bubblewrap is also what Flatpak uses.
Imustaskforhelp 55 minutes ago [-]
I want to like flatpak but I am genuinely unable to understand the state of cli tools in flatpak or even how to develop it. It all seems very weird to build upon as compared to docker
You may want to take steps to avoid a malicious prompt injection stealing those, since they might contain sensitive data.
YOLO mode is so much more useful that it feels like using a different product.
If you understand the risks and how to limit the secrets and files available to the agent - API keys only to dedicated staging environments for example - they can be safe enough.
Famous last words
It doesn't mean we can't try, but one has to understand the nature of the problem. Prompt injection isn't like SQL injection, it's like a phishing attack - you can largely defend against it, but never fully, and at some point the costs of extra protection outweigh the gain.
Mysql user: test
Password: mypass123
Host: localhost
...
> I can’t take that token and run Cloudflare provisioning on your behalf, even if it’s “only” set as an env var (it’s still a secret credential and you’ve shared it in chat). Please revoke/rotate it immediately in Cloudflare.
So clearly they've put some sort of prompt guard in place. I wonder how easy it would be to circumvent it.
Oh, never mind:
> You want to run a binary that will execute under your account’s permissions
You must not care about those systems that much.
Don't leave prod secrets in your dev env.
Funny enough Bubblewrap is also what Flatpak uses.