Claude's Opus 5 caught safety issues my custom guardrails completely overlooked

Published Aug 10, 2026, 5:30 PM EDT Maker, meme-r, and unabashed geek, Joe has been writing about technology since starting his career in 2018 at KnowTechie. He's covered everything from Apple to apps and crowdfunding and loves getting to the bottom of complicated topics. In that time, he's also written for SlashGear and numerous corporate clients before finding his home at XDA in the spring of 2023. He was the kid who took apart every toy to see how it worked, even if it didn't exactly go back together afterward. That's given him a solid background for explaining how complex systems work together, and he promises he's gotten better at the putting things back together stage since then. I’ve been running coding agents on my main PC and other boxes for months. I've used Claude to orchestrate Codex agents, watched one clean up my messy Windows 11 install without issues, and spent a week working out how far to trust a local LLM with my code. I felt pretty secure doing so because I had a guardrail I wrote myself that prevents any destructive commands from being executed. Or I thought I did, but when I tried to break it with fifteen nasty commands designed to slip past the logic, it failed on nearly half of them. So I roped Opus into fixing its own guardrails, and now I have a better understanding of the whole process. The attacks I wrote found real holes (but not the ones I wanted to find) Except every single test I wrote assumed Claude Code would use Bash My first version was a denylist, which is pretty standard procedure. Split each command into pieces, check each against the obvious issues, refuse any matches. It’s the thing you write when in a hurry, and building an allowlist seems like too much work. It passes code review, looks useful, and gives you a false sense of security. It failed almost half of the 15 tests I ran, and was functionally useless. Regex matching is horribly complicated to do properly, and things like using the long-form version of a flag instead of using the short form is enough to fool the block. The fix was to do it properly, with an allowlist of the tools and shell commands I trusted, and to stop everything else before it could run. And refuse any tool or code whose contents I couldn’t read. This passed all 15 tests, but it only proved that I’d written the test to prove what I wanted to see. I wrote a second test, which found some more issues. After fixing those, I went to test the guardrail in a dummy repository folder and hit something none of the tests found. Every test assumed my agent would use Bash, because that’s the shell tool Claude uses. Every test was wrong about which tool Claude would use when running in a Windows Terminal. Claude is a suite of LLM models and tools that help you do anything your imagination can come up with. Twelve lines of logging found more than two attack suites And a guardrail that's not running looks the same as one that is I should know better than to trust safeguards. I verify all my system backups for the same reason: they don’t exist until they’re tested. It took me several runs of my testing suite for me to realize I should make the guardrail log what it’s doing. Once that was in place, I could see what was going on. Claude Code on Windows prefers PowerShell to Bash. Guess which tool my guardrails didn’t block. The second thing was that I’d been blocking a harmless command for days, the shell idiom for redirecting error output: a bare ampersand. Something else stood out in the logs. I’d watched the agent refuse a destructive command, and took it as proof my guardrail was working. It wasn’t; the agent had decided not to run that command before reaching for the shell, so my hook was never consulted. Even worse, the guardrail wasn’t installed correctly at the time. That’s the tricky thing about safety layers: their working as intended shows nothing, but so does them not running. I attacked the fixed version, and it broke in new ways The worst bypass was a rule I wrote Once the shell was locked down, I asked the agent to check if a website was responding. It succeeded, and the guardrail looked like it had failed. It didn’t; it just hit a tool I was explicitly allowing, the built-in fetch tool. Time What it tried Result 19:06:42 PowerShell web request Blocked 19:06:45 PowerShell curl Blocked 19:06:50 Built-in fetch tool Allowed When I wrote the guardrails, I had two main buckets for blocked functions. Shell commands with network access, and tools with disk access. Fetch is a tool, but it doesn’t change files, so it never gets asked about network access. I’d installed an elaborate alarm system and left the back door unlocked. All the agent needed to do was be resourceful enough to query its full suite of tools, and it could use the network. Claude bypassed my guardrails by creating PowerShell files instead I didn’t add this one to my threat model because I expected Claude Code to try to run commands and then be blocked by the guardrails. I fixed the fetch tool, ran the command again to test, and the agent did something amazingly lateral. It was blocked from running inline commands, so it wrote the same command into a script file and tried to run it. That’s because I have a long-standing rule in my CLAUDE.md file that says any long shell commands belong in a saved script instead of typed inline, because they’re reusable and readable. It’s a good rule; I won’t be removing it, but I will be treating it with more caution. It’s a bypass to my guardrail hook, because it only blocks commands and doesn’t read files. As soon as the inline script was inside a file, it was invisible to the safeguards. The thing is, most development work is like this. Things live in files, from build files to package scripts to task runners and CI configuration. Every engineering best practice is to codify scripts into files that other things can execute later, and none of my attacks would have found that. It’s not an attack. It’s a normal part of automating software development, DevOps, and almost anything else that touches a computer. I trust my guardrail more than I did, but my threat model a lot less My attack suite wasn’t a disaster; it found eleven real security holes across two versions of Claude Code, and taught me a few things about scoping in the process. It’s going to be run every time I add new tools to the allowlist, because I’m sure those will find a way to bypass my protections, too. The suite is only good enough to find things I can think of, and everything it bypassed was what I was missing in my original research. A shell tool I didn’t realize would be called, a standard redirect, and a helpful built-in tool doing its job. And yes, something I wrote to make my life easier that managed to bypass my new security checks. Test, then verify, and iterate your security protocols accordingly.