I want claude-guard to be a tool that people actually use, not just because it works but because it works seamlessly. In the alpha test, I only got a single user PR and no issues. I can’t surface everything on my own! I need your data!
The bar is low. If setup failed, doctor confused you, the firewall blocked something you needed, or any other reason you wouldn’t want to use this as your daily driver—any of those is worth a short issue. All you gotta do is run claude-guard doctor --bug-report, which gathers diagnostics into a file you can attach straight to a GitHub Issue. And if something broke, you can get instantly back to work by running claude-guard --dangerously-use-original-claude.
Here’s the pitch from the alpha test:
A ton of alignment researchers YOLO their Claude usage right now. We run Claude on our computers without real protection (perhaps beyond auto mode) but there isn’t an easy way to comply with known best practices. I wrote claude-guard, a wrapper to make best practices easy: just install and then your future claude sessions are protected.
Smart misaligned AI will target alignment researchers in particular for research sabotage, for example by:
Sabotaging their machines to delete key work later (claude-guard protects via sandboxing that goes beyond Claude Code’s Bash-tool-only sandbox),
Poisoning training data using invisible unicode characters (the tool sanitizes inputs and outputs),
Removing traces of its bad behavior (I provide a tamper-evident audit log outside of the sandbox).
My goal is a low-latency, low-fuss product with easy-to-understand restrictions which can be minimally eased to enable common workflows. The ambitious vision is for claude-guard to become a staple open-source tool for AI alignment work, with people contributing improvements using the latest in AI control protocols.[1]
Please give it a try and open issues on GitHub: https://github.com/alexander-turner/claude-guard, or email me at alex@turntrout.com (I likely won’t read comments in any short time-frame). If you run into a blocking issue, please come back a day or two later and hopefully it will be fixed.
Can you make your description of how exactly your program makes it safe to run claude code on my computer more clear? When I skim read the existing description, it talked too abstractly, and also talked too lengthily about some weird dangers such as Claude convincing someone (convince whom? me? some other AI agent?) while not talking enough about actual technical sandboxing. I just want to prevent the LLM from reading any non-whitelisted files on my computer, modifying anything on my computer, and from hacking my computer. I also want to be able to let it use some USB devices or something if I need that for development. Disclaimer: I typically use openai codex instead of Claude.
I finally got around to trying this, but my environment is pretty weird. I already run Claude Code as a separate unprivileged user, but it’s intentionally not sandboxed between agents because I want them to share caches and be able to use shared folders like a wiki. The firewall is also not useful for me since I need agents to be able to run remote experiments via RunPod and to be able to access a local GPU. At some point I’ll probably run all GPU access through SkyPilot, so the firewall would technically work, but agents would still be able to run anything they want from RunPod VMs so it wouldn’t actually block egress for real.
I’m considering the input sanitizer, but since I deal with a lot of coding and tokenization, I’m worried it’s going to sanitize things the model needs to be able to see.
I already run Claude Code as a separate unprivileged user, but it’s intentionally not sandboxed between agents because I want them to share caches and be able to use shared folders like a wiki
Yup, that should be fine. Use CLAUDE_SHARED_AUTH=1 claude-guard is my best guess.
RunPod
There’s a built-in profile for exactly your case: claude-loosen-firewall --profile runpod. Let me know how it works. EDIT: This isn’t quite enough. Working on claude-guard PR #1330.
agents would still be able to run anything they want from RunPod VMs so it wouldn’t actually block egress for real.
Yeah. The fix should be to ssh in and run claude-guard from within the VM.
I’m considering the input sanitizer, but since I deal with a lot of coding and tokenization, I’m worried it’s going to sanitize things the model needs to be able to see.
The input sanitizer library is fairly high-precision, and if that’s not true, I’d love to know it!
Here’s what my Claude says:
Invisible/ANSI stripping (the tokenization worry) is deletion-only over a narrow payload-shaped set, preserves ZWNJ/ZWJ joiners, and never strips silently. The whole layer favors precision over recall — it’d rather miss than mangle real text. You can still inspect exact bytes via xxd/od -c (hex survives), and there are granular opt-outs (SANITIZE_CLAUDE_INVISIBLE_DISABLED=1 / SANITIZE_CLAUDE_TERMINAL_DISABLED=1) if a specific task needs raw bytes through.
I’m going to add a small tool note which lets the agent know how to read the exact bytes if needed, which I imagine solves most issues here even if the sanitizer mistakenly sanitizes some tokens? EDIT: see PR #58.
I just enabled the input-sanitizer and it seems to work. I’m a little worried the HTML comment one might be annoying in some cases, but we’ll see.
The secrets in this screenshot are Claude-generated to look like AWS secrets, not actual secrets.
I also have a plan to enable claude-guard entirely as my Agent SDK backend, but it’s a bit more complicated and I’m going to wait until my Fable rate limits reset. It looks like I can probably get everything I want by maintaining my own worktree logic and just having claude-guard mount the folders and using runsc + nvproxy to share the GPU.
I’ll probably need a way to to use nvproxy locally, a way to expose a port in the container (I have agents run web servers so I can see what a PR would do), and I’ll need to make sure claude-guard passes through Claude Code’s JSON stream so it can be controlled by the Agent SDK. I’ll file issues as needed when I get to this though.
Thanks, I’ll take another look at it. If there’s a way for the agents to know what filtering has been applied and to get around it if necessary that helps a lot. I was mainly worried about cases where an agent is trying to understand a problem with a file but can’t see the file clearly (like UTF-8 BOM character issues).
Call for BETA testers for an AI control/security tool. I’m bottlenecked on bug reports!
I recently advertised the alpha test for
claude-guard. After a few weeks of dev work, it’s now in beta!I want
claude-guardto be a tool that people actually use, not just because it works but because it works seamlessly. In the alpha test, I only got a single user PR and no issues. I can’t surface everything on my own! I need your data!The bar is low. If setup failed,
doctorconfused you, the firewall blocked something you needed, or any other reason you wouldn’t want to use this as your daily driver—any of those is worth a short issue. All you gotta do is runclaude-guard doctor --bug-report, which gathers diagnostics into a file you can attach straight to a GitHub Issue. And if something broke, you can get instantly back to work by runningclaude-guard --dangerously-use-original-claude.Here’s the pitch from the alpha test:
Please give it a try and open issues on GitHub: https://github.com/alexander-turner/claude-guard, or email me at
alex@turntrout.com(I likely won’t read comments in any short time-frame). If you run into a blocking issue, please come back a day or two later and hopefully it will be fixed.This work should complement Apollo’s Watcher, currently a monitoring product.
Can you make your description of how exactly your program makes it safe to run claude code on my computer more clear? When I skim read the existing description, it talked too abstractly, and also talked too lengthily about some weird dangers such as Claude convincing someone (convince whom? me? some other AI agent?) while not talking enough about actual technical sandboxing. I just want to prevent the LLM from reading any non-whitelisted files on my computer, modifying anything on my computer, and from hacking my computer. I also want to be able to let it use some USB devices or something if I need that for development. Disclaimer: I typically use openai codex instead of Claude.
Everything except the USB case should be supported with sandboxing. USB seems hard to support. Does
SECURITY.mdhelp?I finally got around to trying this, but my environment is pretty weird. I already run Claude Code as a separate unprivileged user, but it’s intentionally not sandboxed between agents because I want them to share caches and be able to use shared folders like a wiki. The firewall is also not useful for me since I need agents to be able to run remote experiments via RunPod and to be able to access a local GPU. At some point I’ll probably run all GPU access through SkyPilot, so the firewall would technically work, but agents would still be able to run anything they want from RunPod VMs so it wouldn’t actually block egress for real.
I’m considering the input sanitizer, but since I deal with a lot of coding and tokenization, I’m worried it’s going to sanitize things the model needs to be able to see.
Yup, that should be fine. Use
CLAUDE_SHARED_AUTH=1 claude-guardis my best guess.There’s a built-in profile for exactly your case:
claude-loosen-firewall --profile runpod. Let me know how it works. EDIT: This isn’t quite enough. Working on claude-guard PR #1330.Yeah. The fix should be to ssh in and run
claude-guardfrom within the VM.The input sanitizer library is fairly high-precision, and if that’s not true, I’d love to know it!
Here’s what my Claude says:
I’m going to add a small tool note which lets the agent know how to read the exact bytes if needed, which I imagine solves most issues here even if the sanitizer mistakenly sanitizes some tokens? EDIT: see PR #58.
I just enabled the input-sanitizer and it seems to work. I’m a little worried the HTML comment one might be annoying in some cases, but we’ll see.
The secrets in this screenshot are Claude-generated to look like AWS secrets, not actual secrets.
I also have a plan to enable
claude-guardentirely as my Agent SDK backend, but it’s a bit more complicated and I’m going to wait until my Fable rate limits reset. It looks like I can probably get everything I want by maintaining my own worktree logic and just having claude-guard mount the folders and using runsc + nvproxy to share the GPU.I’ll probably need a way to to use nvproxy locally, a way to expose a port in the container (I have agents run web servers so I can see what a PR would do), and I’ll need to make sure claude-guard passes through Claude Code’s JSON stream so it can be controlled by the Agent SDK. I’ll file issues as needed when I get to this though.
Thanks, I’ll take another look at it. If there’s a way for the agents to know what filtering has been applied and to get around it if necessary that helps a lot. I was mainly worried about cases where an agent is trying to understand a problem with a file but can’t see the file clearly (like UTF-8 BOM character issues).