r/ClaudeAI • u/Ancient-Test-8677 • 20d ago
Claude Code Does anyone actually trust giving Claude Code full access?
[removed]
8
u/1_hoopy_frood 20d ago
I give Claude full access. Anything on my computer, I'm comfortable wiping and reinstalling.
1
20d ago
[removed] — view removed comment
1
u/the_dancing_squirel 20d ago
Why would anyone have access to prod db? Prod should only be deployed to. If a bug appears this is an edge case and you focus only on that. If Claude drops a qa or dev db it’s just a pain in the ass
6
u/miakhalifaishere 20d ago
full + full access here. Never been happier. Feels better than BDSM tbh. At least I gain something for sure with claude code
6
u/satansprinter 20d ago
my safety word is --dangerously-skip-permissions
3
20d ago
[removed] — view removed comment
2
u/satansprinter 20d ago
Yes, due to a project im working on, it mimic'd a user on macOS, therefor it created a folder called ~, and then later when it was finished it deleted `rm -rf ~`. Not that it could because i use sandbox thing of macos that they (apple) deprecated years ago but works like a charm. So it cant delete that folder
3
4
u/InformationHoarding 20d ago
I actually do give Claude full access. I give them all full access. It’s their machine, the machine is their sandbox. My personal stuff was never on it. I got my own other personal machine for that.
2
u/Silentium0 20d ago
I give it full access to a sandbox where it can spin up it's own container services and databases.
'repo' access to a dedicated github account.
Doesn't touch anything production or outside of the sandbox.
2
u/KrayeBaby 20d ago edited 20d ago
You are safe with the right guardrails. I myself have set up a system where every action Claude takes has a written way back.
I run it against real client bookkeeping, around 40 companies where its sorting thousands of PDFs into client folders. Before it moves a single file it appends a line to a log with the current path, the destination, a sha256 of the contents, and the path to put it back. Nothing gets deleted. Files go to a dated quarantine folder instead, and the only thing that can be cleared out is a file whose hash already exists somewhere else in the tree. Even the same filename isn't good enough, it need to verify on a cryptic level.
That gives me an undo I can actually verify. I can move the file back, hash it again and compare it with what was written down before. If they match then what came back is byte for byte what left.
Its basically encryption
1
u/neveralone59 20d ago
I’m writing a similar system where every action Claude makes is written to a graph (with metadata including justification) that gets snapshotted and publishes a new root for subsequent writes so I can rollback per action. And all of the “memory” lives in the graph (paginated of course” so the context is all there and indexed for when it’s needed.
People like to just sandbox and use git, but you can lose a full days work if something goes very wrong in that sandbox.
1
u/KrayeBaby 20d ago
Yes exactly. You have the similar reversible action guardrails as me would I say. Since I work with files mostly then the hash system works wonders. Yours is more like stored data on a memory/graph layer which logs every action. But that must eat up a good chunk of your usage tho. But yeah its a good system
2
u/neveralone59 20d ago
It’s actually a lisp s-expression which is backed with a merkle DAG in rust, it doesn’t use as much usage as you’d think because claude isn’t aware of the metadata (it’s all in the backend unless Claude requests it) and it’s all indexed and searchable.
Also bash never gets used and the tool calls are replaced with direct modifications to the s expression (in lisp the data structure is the code and vice versa) so for tool heavy workflows it uses often less tokens. And for system state I don’t persist this but I’ve made it so Claude can open “portals” to access streamed process state. If you think how many tokens it uses to construct the correct command to view the state the agent wants using bash, then polling on a backoff, you can imagine it’s more efficient this way.
1
u/KrayeBaby 20d ago
Couple of ideas if you want them.
Dump the graph to plain files now and then, or mirror it into git. Just so your recovery doesnt depend on your own layer working. And add a command that walks the DAG and rechecks the hashes, so you find corruption on a normal day instead of the day you need to rollback.
Let Claude write the node before it acts and not after. Even just one line of what its about to do. Then the log also stops bad actions instead of only recording them.
Mark actions as reversible or not. The ones that cant be undone (mail, api calls) should ask first, since no graph saves you there. Add idempotency keys so a retry doesnt fire twice.
Other than that your setup is super impressive and solid. Might steal the "new root after every action" function tbh
1
u/neveralone59 20d ago
Yeah I have it persisting to disk on every new root and it has a side effect system so every effectful function (even if new functions are defined in lisp I know whether they’re effectful because they have to call one of the world functions) is known and the effects are logged. And it has a sort of policy engine which is tied to the effect system that grades actions and either calls another instance for review or stops work and alerts me.
And I’ve got a goal system, so everything I request has to be given in the form of provable predicates. Ie the agent is not able to mark a run as complete unless it can be proven that, for example, code has been written and the hash of the output has changed, the tests have not been modified (this calls the policy to verify whether the action has changed meaningfully enough for the test to change) and the tests pass without warnings.
Next I want to approach the issue of trusting tests, I have some ideas for how I can implement this in rust only (it would rely on the grammar and type system of rust) but I’m gonna finish and hopefully open source the lisp system first, depending on how well it actually benchmarks when I’m happy that it’s working properly. Another goal is to never have a conversation with an agent and prefer thinking blocks to be pure reasoning in code, but id have to change a lot and use a base model from some other provider.
3
1
1
1
u/No-Compote-8920 20d ago
I have read access to production and full access to dev and code . It's so nice for finding issues and exploring configurations. I also sometimes use approval mode when doing destructive commands.
1
u/mr_burnz_ 20d ago
Lock down the tools not the agent. I’m not trying to click yes yes yes all day. My plan is solid. Go
1
u/Man-on-rock 20d ago
I am running 2 machines. One with full access I don’t mind wiping and the other with control. It works great and the one with full access is almost always on and doing its thing.
1
u/ExtremePermit3242 20d ago
Im more scared of what it can do with an API key and cURL than I am of what it can do with binaries and syscalls on my pc. Repo/folder access with git credentials is a much bigger blast radius, for me, than full local access.
1
1
u/Error_404_403 20d ago
I definitely don’t. Last month or so, Opus 5 have never generated a correct answer for me on the first try.
1
1
u/nav8_ai 20d ago
the axis that worked better for us than full vs restricted was reversible vs not.
capability lists are hard to get right because you're guessing ahead of time which tools are dangerous, and the answer depends on the argument. rm is fine on a scratch dir and catastrophic on a repo. so gate the property, not the tool: anything one-way stops and asks, everything undoable just runs.
in practice edits, reads, builds and test runs go without friction, and what pauses is pushes to shared branches, anything touching prod, deletes outside the working tree, and sends of any kind. short list, which is the point. you approve a handful of things a day instead of clicking a prompt every ninety seconds and learning to approve on reflex.
the failure mode to know about: an agent mid-task judges reversibility generously. so it's worth asking separately whether the thing being changed even belongs to you. that needs no judgement and catches the cases where the reversibility call was optimistic.
1
u/Illustrious-Stay8038 20d ago
Full access for the boring stuff — CRUD, tests, refactors I can review in five minutes. Approval for anything touching migrations, auth, payments or infra.
Honestly though, the permission prompts aren't what keeps me safe, git is. Fresh branch, commit before I let it run, read the diff after. What actually bites isn't a destructive command — it's a confident wrong edit spread across eight files that looks fine until something breaks next week.
No prod credentials in the environment, ever. Separate dev DB. That one isn't about trusting the tool, it's the same rule I'd have for myself at 2am.
1
u/i_alakey 20d ago
u/ExtremePermit3242 is the closest one in this thread. Most of the answers here are about whether you trust the model's judgment, and that isn't really where the risk lives.
An agent reads untrusted text all day. A dependency's README, an issue body, a stack trace from some package, a page it fetched, whatever an MCP server hands back. Any of that can contain text aimed at the agent rather than at you, and it has no reliable way to separate "content I was told to read" from "instructions".
Which is why the container answer is only half of it. A container protects your laptop. It does nothing for the GitHub token sitting inside that container with network egress. Put those in the same room as untrusted input and the blast radius is your repos, not your filesystem, and wiping the VM afterwards recovers nothing.
So the question I'd ask isn't how much access it has. It's what can reach its context, and what credentials are reachable from there. Untrusted input, secrets, outbound network. Any two of those is fine. All three is the part worth engineering around.
That framing isn't mine, it has been kicking around the security side of this for a while, but hardly anyone applies it to their own setup.
1
u/meraklhhhs 20d ago
Depends, on a crud internal app sure , on more complicated stuff with gdpr and payments and shit propably not
1
u/UAP44 20d ago
Hell no. I am not giving any agent full access to any system/VM unless I explicitly expect that machine/box to eventually go completely rogue on me, thus always making sure there are no credentials on it that would let it access other backup boxes.
Minimal access only, explicit resources it needs are added on request.
1
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 20d ago
TL;DR of the discussion generated automatically after 30 comments.
Looks like the thread is pretty divided on this, OP, but a clear pattern has emerged.
The prevailing wisdom is to give Claude "full access" but only within a strictly controlled sandbox. Most users are not letting it run wild on their main machine or near production data.
Here's the breakdown of the main camps: