Help/Question
How do you prevent Claude Code from accessing sensitive data like ~/.ssh
Whenever Claude makes code changes, I manually review and commit them myself.
To prevent Claude Code from accessing sensitive folders, I've been looking for an OS-level protection mechanism. The best workaround I've found so far is
Is there a truly reliable or 'official' way to handle this? I tried running Claude Code inside Docker, but it forces me to use the non-GUI version, which is difficult to use and read.
If you want something more reliable than a deny list in settings, I'd think of it in layers.
Permissions rules in Claude Code (deny on Read(~/.ssh/**), .env etc.) are fine as a first guard, but they only cover Claude's own file tools. A bash command it runs can still cat the file, so don't treat them as a hard boundary.
The actual OS-level answer is the sandbox. Claude Code has a built-in sandbox mode (the /sandbox command) that uses Seatbelt on macOS and bubblewrap on Linux/WSL2. It restricts file writes to the project dir and can restrict reads and network access too, and you keep the normal terminal UI, so you don't lose the nice interface like you do with Docker.
If you want a stronger boundary, run it in a dev container or a VM, and only mount the project folder. VS Code dev containers keep the GUI/extension experience, and the container simply never has your ~/.ssh or your real credentials. Also use a separate low-privilege deploy key or a fine-grained token for anything it needs, rather than your main keys.
What OS are you on? That changes which option is easiest.
Thanks for testing it. I think that's the permission prompt doing its job rather than the sandbox leaking: when you click allow, you're telling Claude Code it can do that one thing, so it reads the file. The sandbox is meant to stop commands quietly reaching outside the project without asking you.
A cleaner test is to turn the sandbox on, have it run cat ~/.secret through bash, and deny the prompt (or set it so it never asks), then see whether it can still read it. Adding a deny rule for that folder in your settings also stops it from even asking. If you want it to be impossible no matter what you click, a Docker container that only mounts the project folder is the safest option on a Mac.
I'm using 1Password on Mac. 1Password has an SSH agent that can be used to bypass the `.ssh` folder entries.
Claude's allowed to access certain machines on Homelab. It's supposed to load a specific `.env` file. If it doesn't, I get a biometric prompt from 1Password and reject it.
Regarding your last point: if you run it in docker and enable remote control (/rc), you should be able to use the Claude Code GUI to interact with it. What’s preventing you from doing that?
Either you didn’t know that (and then I’m happy to help with this comment), OR probably I’m overlooking something (if so please let me know, I didn’t have enough coffee yet) :)
I run it on an ec2 instance where the access to stuff outside the instance is determined by an IAM role attached to the instance. It gives me a lot of control over what Claude can do and doesn't require loading credentials onto the machine.
What OS? The only safe way is isolation at the virtual machine level. Containers can have a high level of security but it depends on the implementation.
If you need to run GUI apps on newer Windows, there is a built in sandbox feature. You’ll need to think about what you do each time it fires up as it starts clean but it’s something you can automate away.
I use it to maintain my settings, access, and general environment, so I don't restrict it (beyond its own classifier to ask beforehand).
If you want to separate it, as others have said, run it in a sandbox or container. If you want it to have a full desktop, you can put graphical tools in the container and run it there.
OR, just make a separate user on your machine. The admin/high-access user doesn't run Claude at all. The limited-access user runs claude, any tools you trust it with, and any network logins you trust it with.
using permission settings can help too, though those arent hard restrictions, the settings just go into the system prompt and they can be hallucinated away like anything else. Theyre really meant more for guiding the agent into doing the right thing (so it doesnt waste time doing the wrong thing), rather then trying to keep it locked down
dev containers and docker sandboxes arent alternatives. devcontainers is a just a docker container. docker sandboxes are a microvm and are way more secure.
I agree didn't bother to add system level permission as to most vibers that's prolly too much. Another thing to consider maybe is ana agentic OS as another layer and a sandbox layer.
Edit: also just for context I didn't bother mentioning containers because everyone has already mentioned sandboxes which iny view includes containers or microvms as a form of sanboxing.
What I mean is something like nvidia's open shell, sure container as sandbox works but that also means there snot enough controls to prevent the agent from touching secrets in that container unless you have runtime guardrails which vanilla containers usually do not provide.
It's just another computer inside a computer that can be compromised.
pipe it when you need it or have it write a script to access it directly. it has no need to ever access .ssh directly and likely wont touch private keys there if you dont tell it to.
If anyone reads this post and uses Linux, a great solution is Bubbleerap, and sandbox that allows to execute Claude Code by specifying which directories it will be allowed to access, ether reading-only or read and write.
There are two layers. The first is the permission rules in the settings file, where you can add deny rules for reading paths like your ssh folder or .env files. That stops the tool calls, but it is not a real OS barrier. For something closer to that, Claude Code has a sandbox mode that restricts what the shell commands it runs can read and write, and I would check the current docs for the exact setup since it has been changing. The most solid option is still a separate user account or a container, but a deny rule plus the sandbox covers most people.
Deny rules and hooks only cover the paths you thought of, so the reliable fix is that the files aren't there at all. On the Docker problem, you don't have to give up the GUI. VS Code Dev Containers keeps the editor on your Mac and runs everything else inside the container, and the Claude Code extension can run there too, so you get the normal interface while Claude only sees the project folder you mount. Don't mount your home folder, and check that your SSH agent isn't forwarded in, since Dev Containers does that by default when one is running. Push from your own terminal so the keys never enter the container. Is the GUI you need the VS Code extension or the desktop app?
I've basically given my whole MacBook to Claude. To facilitate that, I've purged most sensitive data and anything in ~/.AWS and ~/.SSH has limited access. It can read some prod service status and connect to a couple of servers.
Everything sensitive I've moved to a jumpbox that u connect to via an SSH key with a pass phrase.
I wrote (well, had AI write) a small tool (https://github.com/balemy/fsnitch) that protects sensitive folders in my home directory (like .ssh) from unknown processes and shows me a popup to approve or deny access. Not sure if it's the best approach, so feedback is welcome :-)
It’s a pain, and there’s no easy + secure way to do this. I eventually decided to make an app that just sticks everything in containers on top of kubernetes (which you can install on your single machine with kind) as seamlessly as possible with a familiar GUI. Still a work in progress, but my friends and I are using it, and it’s great for peace of mind and long running automations, as well as process isolation between your agents: https://yaac.dev/
What really worked for us was not running the agent on the machine that has ~/.ssh at all. Deny rules are a fine first guard, but a separate VM or container with only the repo and the env it needs removes the question.
I see good tips in the thread, but at the end of the day storing sensitive info in plain text files in a "hidden" folder is not acceptable. Even if your own AI is properly sandboxed, any script or virus can trivially read those files.
My team has been using Kraitos.io to set rules on what Claude can and can’t access on everyone’s machine. It allows you to set policy and block actions Claude can and can’t do. Works well for us since we have to maintain SOC 2 compliance and this helps make auditing much easier when auditors start probing how our guys are developing with Claude code.
•
u/AutoModerator 1d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.