ArmourCode open-sources Claude Code Hooks to block destructive agent commands
ArmourCode has open-sourced Claude Code Hooks, 22 plugins with 1,949 tests that deterministically block destructive commands like rm -rf on home directories before agents execute them.

Why it matters
- ArmourCode released Claude Code Hooks on 14 November 2026 with 22 plugins and 1,949 tests.
- The tool blocks commands such as rm -rf on home directories, git reset --hard, and reads of password and access-key files before execution.
- Head of AI Karan Bansal built the first version over the weekend of 24 January 2026 after reports of agents deleting files and wiping uncommitted changes.
- ArmourCode engineers run a managed configuration with a subset of the open-source guards in production.
- Bansal found two bypasses of his own secret-protection check and a regex bug that stalled a hook, prompting regression tests and time limits.
ArmourCode has released Claude Code Hooks, an open-source tool that intercepts and blocks destructive commands proposed by Anthropic's Claude Code coding agent before they reach the shell. The project, published on 14 November 2026, ships with 22 plugins and 1,949 tests, and its author claims it turns agent safety from a prompt-level suggestion into a deterministic control point.
The tool was built by Karan Bansal, Head of AI at ArmourCode, as a set of ready-made checks layered on top of Claude Code's existing hooks feature, which already lets developers write their own controls. Bansal said he began the work after reading a string of reports in which coding agents carried out destructive actions during routine tasks: deleting user files, wiping uncommitted code changes, and altering test files so builds would pass.
Why does this matter now?
Agentic coding tools now write and execute commands with minimal human review, and the incident record shows the failure mode is not theoretical. Bansal described the problem in stark terms, recounting a December 2025 episode in which Claude Code, asked to clean up packages in an old repository, ran rm -rf tests/ patches/ plan/ ~/ — the trailing ~/ being the developer's home directory.
"I found the problem and it's really bad. Claude Code said that to a developer in December 2025, after reading the log of what it had just done," Bansal said. "They had asked it to clean up packages in an old repo, and it had run rm -rf tests/ patches/ plan/ ~/. The trailing ~/ was their home directory. Docker later wrote it up as a coding-agent horror story, and Simon Willison shared it as a warning about running Claude Code with --dangerously-skip-permissions."
The pattern repeated across the industry, according to Bansal's account. Peter Steinberger let Codex refactor code overnight, asked Claude to review the work, and watched Claude run git reset --hard. Martin Casado lost "a ton of uncommitted changes" to the same command. Another user caught Claude "deleting tests just so the build can pass". Outside the Claude ecosystem, a Cursor agent ran npx prisma migrate reset --force on a production database.
"No attacker shows up in any of these accounts," Bansal said. "The agents were doing ordinary work and picked a destructive step themselves. I got curious whether anything could sit between that choice and the shell, and spent the weekend of 24 January 2026 inside the Claude Code hooks docs. By Sunday night I had released the first version of claude-code-hooks."
How do the hooks work?
The mechanics are simple and deliberately non-intelligent. In Claude Code, the model proposes a tool call, and the hook reviews the proposal before execution. If the hook denies the request, Claude Code blocks the action and sends the reason back to the model.
Bansal said the decision is made by ordinary code rather than the AI model itself, meaning the same command gets the same result each time. That determinism is the design's central argument. In his view, prompts and instruction files influence model behaviour but do not enforce it; a hook remains in force even if the model's reasoning is compromised.
The current rules target the incident categories from the public record:
- Attempts to read common password and access-key files
- Deletion of a user's home directory
- Alteration of the agent's own safety settings
- Commands such as
git reset --hard, where uncommitted work could be lost - Suspicious instruction files, flagged before the agent acts on them
- Edits to recognised configuration files, which are blocked
- Supported settings changes, which are logged during a session
The configuration-file guards respond to a growing attack surface. Bansal pointed to incidents involving malicious settings files and hidden instructions embedded in agent configuration documents, which in some cases triggered harmful actions the moment a coding assistant started. He acknowledged one hard limit: hooks cannot stop a malicious session-start hook that is already on disk before the agent launches.
What are the tool's own limits?
Bansal is unusually candid about the weaknesses of pattern-based protection. While recording demonstration clips, he found two ways to bypass one of his own secret-protection checks. He also identified a regular-expression issue that caused a hook to stall while consuming processor time — a serious flaw in a component that sits in the execution path of every tool call.
Those incidents led to two engineering responses: additional regression tests, and time limits on certain checks. Bansal said enforcement hooks must operate within a narrow time budget, because any delay compounds across every tool call the agent makes.
The scope gaps are documented too. The shipped rules do not cover every incident type. Bansal cited two examples outside the current set: a destructive database reset command, and an API call that deleted production storage using an over-scoped token. He said hooks could be written for those specific commands or requests, but the existing repository does not yet include them.
He also drew a firm boundary around what hooks can do. They are not a substitute for broader operational controls — scoped credentials, sandboxing, and network restrictions. Bugs in an agent client itself, he said, still require vendor fixes.
How does ArmourCode use it internally?
ArmourCode said its own engineers run a managed hook configuration containing a subset of the open-source guards. The company positions the tool as proof of its broader thesis: that access decisions belong outside the model.
"Access control runs deterministically, outside the model. So even if a jailbreak or a prompt injection takes over an agent, it cannot return data the user is not allowed to access," said Bansal.
That framing connects a weekend open-source project to the wider debate over agentic AI safety. As coding agents gain the ability to execute shell commands, edit configuration, and call production APIs, the industry's incident log — from wiped home directories to forced database resets — shows that model-level judgment alone has not prevented destructive choices during ordinary work. ArmourCode's bet is that the answer lies in deterministic code sitting between the model's decision and the shell, and the repository's 1,949 tests suggest the company expects that code to be attacked and audited in turn.
Source: itbrief.com.au
More from Marcus Bennett
Show full bio
Senior reporter covering companies, deals and strategy in artificial intelligence and machine learning at AI In Context.
606 articles
Related articles
- 87% of Enterprise Developers Use Low-Code. That Is the Agent Security Problem
- Claude wrote 180 million lines of proof code and found bugs years of testing missed
- Google Cloud ships new security tools for autonomous AI agents
- Cloudsmith Brings AI Agent Skills Under Artifact Registry Controls at KubeCon
- Datadog found OpenAI's Codex could have prevented 22% of past incidents