Claude Safety Is Out of Hand, and That Probably Isn't a Bad Thing

Last week my Codex plan ran out of tokens so I decided to give Claude Code another go. I had recently moved away from it because I kept hitting the API error wall that had become commonplace for me when using Claude.

API Error: Claude Code is unable to respond to this request...

That became increasingly frustrating because I was not using Claude for anything especially sensitive at the time. I was not asking it to do cyber work. I was not asking it to break into anything. I was trying to build normal product features, fix normal files, and keep moving. During my break from Claude I also learned that Codex was actually decent, and often better than Claude Code for a fraction of the price, but that is probably a separate post.

The reason this is complicated is that I do not actually think Claude is wrong to have strong safety systems. I watched the Four Corners episode on AI last night, and it made the whole thing feel less simple. The future we are moving into with AI is obviously powerful, strange, and not fully understood. These systems are already being pushed into work, education, software, medicine, law, relationships, and decision-making. So no, I do not think the answer is “turn the safety off.” That would be stupid.

Claude safety is out of hand

There should be safety. There should be refusals. There should be lines these systems do not cross. The problem is that there is a difference between a line and a panic button.

Why is this bad and how do you avoid it?

My world touches security. I work around vulnerability discovery, recon, testing workflows, and code that explores where systems break. That means security-adjacent tooling sometimes lives in repositories beside completely ordinary product work. The work Claude kept refusing was not the security work. It was the boring work. I would sit down to build something mundane for Atlas AI, and because there was security-flavoured code somewhere in the broader repo, the safety layer would lock up. Not just on the sensitive file. On the config, the test, the README, or whatever normal thing I was actually trying to ship.

That is what cost me my time, and my patience (I swapped to Codex). The tool that was meant to speed me up kept stalling on the everyday tasks it is normally best at.

Claude Code does have a workflow escape hatch. You can hit escape twice to rewind the conversation, and sometimes that is enough. But in my experience, once a session has been shaped by a cyber refusal, the context is very hard to recover. The agent starts treating the repo differently. A rewind might get you back a few steps before the refusal, and /clear might reset the conversation, but neither one changes the thing that caused the refusal in the first place. The only reliable workaround I have found is swapping to a “dumber” model like Sonnet to get the work done. Even then, when I swap back to Opus, I hit the same walls again.

Once context is polluted, work stops

After refreshing the context, the repo is still the repo. The same words are still there. The same file names are still there. The same harmless references to 'suspicious' tools are still there. So you can clear the conversation, start fresh, and still walk straight back into the same wall because the active workspace is presenting the same signals again.

That was the point where I realised the problem was not only the agent. It was the shape of the workspace I was asking the agent to reason inside.

The Solution

I built a small skill called repo-sanitize. Its job is simple: triage on capability, not vocabulary. The files that actually carried sensitive capability got archived. The ordinary code stayed where it was. References were cleaned up. The build still had to pass. And importantly, nothing was deleted.

The aim was not to hide anything, and it definitely was not to pretend the code never existed. The files went to a dated archive outside the active tree, with a manifest and a restore path. I wanted the agent to stop tripping over the same words every time I opened the repo. I did not want to rewrite history.

The fix was not “how do I trick Claude into helping me?” The fix was “how do I stop handing Claude a messy context and then getting annoyed when it reacts badly?” Because once the context becomes polluted, rewinding is not always enough. Clearing is not always enough. Sometimes the practical fix is to remove the ambiguous capability from the active tree, document the decision, and let the agent work on the ordinary code without dragging the whole repo through a safety argument every time.

• Trigger words are not evidence. Capability is.
• Author once, run everywhere

There was a second problem hiding behind the first. I do not work in a single agent. I move between coding agents depending on the task, and a fix that only works in one of them is half a fix.

So two habits earned their keep. First, I lean on a skill that makes skills. When I work through a process manually and realise it should exist again, I turn it into a reusable agent skill with clear rules, structure, and acceptance criteria. That is how repo-sanitize went from a one-off cleanup into something repeatable.

Second, I wrote a small bridge so a skill I author in one agent can show up in the others without me copy-pasting folders around and watching the copies quietly drift apart. Write the fix once, use it everywhere.

I have used this pattern for a while now but repo-sanitize was the first thing I pushed across the bridge that made me realise that making it public might be helpful to others.

Why I am sharing it

None of this is complicated. It is not much code. It is mostly one clear rule: triage on capability, archive reversibly, and keep the fix portable across the agents you actually use.

But it gave me my day back, and it changed how I think about AI safety in the tools I use every day. My first instinct was frustration. Claude was blocking me. Claude was wrong. Claude was wasting my time. I still think that is true in a practical sense. The refusals were blunt, they got in the way, and they treated ordinary files like they were part of the problem.

But after watching Four Corners, I find it harder to argue that AI companies should just loosen everything and hope for the best. They probably should be paranoid. The stakes probably are high enough for that. The problem is that blunt paranoia is still blunt.

The stakes are too high to get this wrong

Safety that cannot tell the difference between dangerous capability and scary-looking language becomes its own kind of failure. It breaks flow. It wastes time. It makes normal work feel suspicious. And once that refusal gets into the context, your work stops - until you run my skill!

So I do not think this is a simple anti-safety rant. Claude safety is out of hand, and that probably is not a bad thing. It means the problem is real enough that the brakes exist. But the brakes still need to get smarter if any of us are ever going to get hold of Mythos.

For now, my fix is simple: make the boundary visible, archive what actually crosses it, keep the ordinary work clean, then get back to building.

References

• The AI Race - Four Corners Episode
• repo-sanitize skill
• cross-agent-skill-bridge skill