HOL Guard: what it checks in Claude Code, Codex and Cursor

HOL Guard is a free, open-source app that sits between an AI coding agent and your machine. When Claude Code, Codex or Cursor is about to run a destructive shell command, read a file that holds secrets, call an MCP tool or install a package, Guard applies a policy and allows the action, asks you, or blocks it. It runs locally, needs no account, and is licensed under Apache-2.0. An optional cloud tier starts at $4.99 a month.

I had Claude Code install Guard on my Windows machine and try it. Within five minutes Guard was reviewing the agent that had installed it, and it held seven actions in a row, including git status. This post covers that session, how Guard hooks in, the gaps its own documentation lists, what it costs and what a connected machine reports.

What it is and who makes it

Guard comes from HOL, short for Hashgraph Online, which describes itself as building "open infrastructure for AI agents". The code is on GitHub at hashgraph-online/hol-guard and the command-line tool is published on PyPI as hol-guard.

Some numbers, all read on 14 November 2026:

• Age: the GitHub repository was created on 28 March 2026.
• Popularity: 1,105 stars and 273 forks.
• Latest stable release: 3.59.0, published on 4 November 2026.
• Release pace: PyPI carries files for 197 stable releases, the oldest uploaded on 7 July 2026. That is more than one stable release a day on average, with pre-release builds published several times a day on top.

The pace cuts both ways. Bugs get fixed fast, but the 3.59.0 release notes cover 915 merged pull requests and say "This release spans too many changes to list". For a tool that sits in front of your shell, that is a lot of change to take on trust between two versions.

What happened when I installed it

The setup: Windows 10 on x64, Python 3.15.2, Claude Code running in VS Code, and no Guard Cloud account. Guard ran natively on Windows, not in WSL. I asked Claude Code to do the install and the testing, with a throwaway project folder as the target.

Installing took 20 seconds. The agent used uv tool install hol-guard==3.59.0, which is uv's equivalent of the pipx route in the README. It put three commands on the machine: hol-guard, hol-guard-eval and plugin-guard.

The first check failed, slowly. Guard can tell you how it would judge a command without running it:

hol-guard command test 'rm -rf ./build'

The first run took 64 seconds and answered NATIVE_UNAVAILABLE, with the reason "Native inspection is unavailable." The same command a moment later took 2.9 seconds and answered REVIEW, matching the rule command.filesystem.recursive-delete. So the native runtime needed a cold start, and the first answer during it was wrong in the unsafe direction: no match.

Two more inspections behaved sensibly:

• git reset --hard HEAD~3 came back as REVIEW, classed as a destructive Git command.
• git clean -ndx came back as NO_MATCH, which is right, because -n makes it a dry run.

Those inspections started a background service. After them, several hol-guard-runtime.exe processes were running, a ~/.hol-guard folder existed, and an approval center was listening on 127.0.0.1:5285. Nothing in the Claude Code settings had changed yet.

The hooks went into the global settings, not the project. The agent ran the install with a workspace flag pointing at the throwaway folder:

hol-guard install claude-code --workspace <throwaway-project>

It finished in 4.6 seconds and said: "Hooks are installed globally", adding that "the workspace only scopes the hook URL and Guard policy." The file it changed was ~/.claude/settings.json. That differs from the repository's support matrix, which describes installs into .claude/settings.local.json. The effect was immediate, with no restart: Guard was now reviewing every Claude Code session on the machine, including the one that had just installed it.

Then it held almost everything. These are the agent's next actions, under Guard's default policy:

Action	Result	Guard's stated reason
ls on the test folder	Ran
A search with Claude Code's Grep tool	Ran
Reading a file in a temp folder with the Read tool	Ran
A six-step chained shell command	Held	"Steps 2, 3, 5 (python, ls, ls) are not proven read-only"
Reading ~/.claude/settings.json	Held	"Guard could not verify" the path "as a path that is safe to read"
cat .env on a file holding a fake key	Held	"requires fresh approval under the installed policy's secret read setting"
rm -rf on the test build folder	Held	"this command could not be confirmed read-only"
git status --short	Held	"this Git read may execute a configured helper, or its effective configuration could not be verified"
pnpm content, this site's content build	Held	"requires review before this package or script command can execute"
hol-guard status	Held	"this command could not be confirmed read-only"
Small file edits with the Edit tool	Ran
One full-file write of this post with the Write tool	Ran, then flagged	After the write: "requires fresh approval under the installed policy's persistence setting"

Seven holds arrived in about 80 seconds. Each one came back to the agent at once as a failed tool call with clear instructions: the action is waiting in the Guard inbox, do not retry it, carry on with other work. Claude Code followed that and did not retry.

File writes were the exception to the holds. The edits to this post were not stopped. One large write was flagged, but only after the file was already on disk, and Guard's message did not say what about it touched the "persistence" setting.

Three things I take from the session:

• The blocks are real. On Windows, which HOL marks as experimental, the secret read and the recursive delete were both stopped before they ran.
• The default policy is strict. It does not only stop dangerous commands. It holds anything it cannot prove is read-only, and that included git status and the project's own build script. An agent session under these defaults stops constantly until you approve requests or relax the policy.
• Set the approval gate first. Guard's install output warned that "Local Guard approval protection is not enabled" and recommended a password or MFA "so only you can approve blocked actions". The hold message that the agent receives includes a link to the approval center with a session token in it. I did not test whether an agent can approve its own request through that link, and I would turn the gate on before relying on Guard.

Getting to the inbox was its own problem. Opening the approval center's address in a browser showed "This approval link needs a signed local session". Running hol-guard dashboard in a terminal, twice, printed "Dashboard unknown" and "Browser opened no", and no browser window appeared.

The terminal route worked:

hol-guard approvals approve <request-id>

It printed "Approval resolved" with the action "allow", and when the agent retried the identical pnpm content, the command ran. The approval covered that exact command, once. The next script, pnpm lint, was held as a new request, and so was a second pnpm content a few minutes later.

How it hooks into each agent

Guard does not patch the agents. It registers itself with the hook systems they already expose, so the agent calls Guard before it acts. The repository's support matrix describes the three most common setups like this:

Agent	Where the matrix says Guard installs	Hooks it uses
Claude Code	.claude/settings.local.json (in my test: the global ~/.claude/settings.json)	PreToolUse, PermissionRequest, UserPromptSubmit
Codex	Hook entries in .codex/config.toml	PreToolUse, PermissionRequest
Cursor	.cursor/hooks.json	beforeShellExecution, beforeMCPExecution, preToolUse, beforeReadFile

Each check ends in one of three outcomes: allow, ask or block. An "ask" goes to the agent's own approval prompt where one exists, or to Guard's approval center. Every decision is written to a local record that Guard calls a receipt.

Two details from that document stand out:

• Codex with approvals off. The matrix says shell commands "can be denied before execution even when Codex itself is running in YOLO mode". If you run Codex with its own prompts disabled, that is the claim worth testing first.
• Cursor keeps its own prompt. For "ask" decisions, Guard leaves Cursor's native tool approval in place and does not add a second one.

The README lists 16 supported agents in total, including GitHub Copilot CLI, Cline, Gemini CLI and OpenCode. Coverage differs for each, which is the next section.

What it does not cover

Because Guard depends on hooks, it only sees the events an agent chooses to expose. HOL publishes a coverage table and a page of blind spots. For the three agents above, they say:

Agent	Events Guard sees	Gap HOL states
Claude Code	Shell, MCP tool, file read, tool result	"Prompt events and background agent sessions that run without an active terminal do not surface hook events to Guard."
Codex	Shell, prompt, MCP tool, file read, tool result	"Inline file edits applied directly by the model without a tool call are not visible to Guard."
Cursor	Shell, MCP tool, file read	"Shell commands issued through Cursor's built-in terminal bypass Guard unless the terminal runs inside an agent session." Prompt submission is not covered either.

Five things follow from those two pages:

• File writes are not on the list. None of the three rows includes file writes as an event Guard sees. In the stable table, only Cline and Grok Build do. My session was close to that: while shell commands were being held, Claude Code's file edits went through, and the one write Guard objected to was flagged after it had happened.
• The documents disagree about Claude Code prompts. The coverage table says prompt events are not surfaced. The support matrix in the repository says Guard has UserPromptSubmit coverage, "so a typed prompt is screened before Claude reads it". I could not tell from the documents which one describes the current release.
• The coverage table is past its own expiry date. It was reviewed on 9 September 2026 against version 3.0.1 and is marked "expires 2026-10-09". The current stable release is 3.59.0.
• Some integrations fail open. For Kimi Code, Grok and ZCode, the support matrix says the hook "fails open if a hook crashes or times out". If Guard is unreachable, those agents carry on unchecked. For Claude Code, Codex and Cursor the table gives the fail behaviour as "surface specific" and does not define the term.
• Installed is not the same as working. The support matrix says "file presence and synthetic canaries do not establish a live block". Test a block yourself, as above, before you trust it.

HOL is also direct about what the product is not. The blind-spots page lists four things Guard does not claim to be:

• "traditional endpoint antivirus"
• "universal model-level prompt-injection filter"
• "replacement for SCA or dependency scanning"
• "support for every action in every harness"

The first of those sits oddly next to the README, whose headline is "HOL Guard: Open-Source Antivirus for AI Agents". The features page is the more careful source. It says Guard "is not a perimeter network firewall or a universal prompt filter, and it does not replace endpoint, DLP, identity, or secrets-management controls."

What it costs

Prices are from HOL's pricing page, checked on 14 November 2026.

Plan	Price	Cloud-connected devices	Cloud retention
Free	$0	None, local only	None
Solo	$4.99 a month	2	30 days
Pro	$15 a month	5	180 days
Team	$30 per seat a month	Up to 25	365 days

The free plan is described as "Free forever on one machine. Local leaked-secret scanning, runtime protection, approvals, and receipts do not require an account or cloud connection." The paid plans add synced approval history, alerts and, on Team, shared policy.

The page advertises two months free on annual billing but I did not find the annual prices in its text. It also says trial and payment terms are shown at checkout, so read those before you enter a card.

What leaves your machine

With no account, the documentation says nothing needs to. Local protection, approvals and receipts work without signing in, and my test ran that way.

Once you connect a machine to Guard Cloud, the repository's local versus cloud document says it sends "a small fleet posture summary: Guard version, OS, which AI tools are protected, installed skill and plugin inventory, and the applied policy."

You can reduce that to version, protection state and policy status:

hol-guard settings set fleet-posture off

The same document notes that "managed installs cannot opt out". If your employer rolls Guard out to you, the inventory of your installed skills and plugins goes to the company's workspace.

Installing it

The README's route uses pipx and needs Python 3.10 or newer:

pipx install hol-guard
hol-guard init

The README says the first-run wizard "asks before each setup change", including installing agent integrations and connecting cloud services. To add one agent yourself and then check the setup, the install page gives:

hol-guard install claude-code
hol-guard doctor

To remove it, the same page gives:

hol-guard daemon stop
pipx uninstall hol-guard

The installers, the desktop apps and the hosted documentation are on HOL Guard's site. The desktop apps cover Apple silicon Macs on macOS 13 or later, Windows x64 and Linux x86_64. The platform table lists macOS and Linux as supported and Windows as "Experimental", with "WSL recommended".

Rough edges in the issue tracker

The repository had 23 open issues on 14 November. These three are user reports I have not reproduced, but they show where the friction is:

• #7485: after a restart on Linux nothing starts Guard, and Claude Code prompts are refused without saying Guard is not running.
• #6263: on a 3.58.0 pre-release with Claude Code, an approved request did not let the identical retry through.
• #3837: approvals match the exact command, so when the agent rewords its retry it needs a new approval.

All three are about the approval loop. Given how many requests my short session produced, that loop is the part of the product you would touch most often. My one approval behaved better than #6263 describes, since the identical retry ran, and it matched #3837: the approval was for the exact command.

Is it worth trying?

This is a first impression from one session, not a verdict.

Claude Code, Codex and Cursor already have their own permission prompts, and I compared two of them in Cursor vs Claude Code. What Guard adds on top is one policy across several agents and a record of what was decided. That makes it most interesting in three cases:

• You use more than one agent and want the same rules in all of them.
• You run an agent with its own approvals turned off and want a backstop for the destructive commands.
• You need an audit trail of what agents did on a machine.

If you use a single agent and keep its permissions tight, the gain is smaller, and you are adding a fast-moving dependency in front of every tool call. Either way, budget time to tune the policy. Out of the box it stopped routine work as readily as risky work.

What my session did not answer:

• Can you approve a class of commands, so that each new script does not need its own approval?
• Why did the dashboard not open on this machine?
• How much delay does each check add to a tool call that is allowed?
• Does Guard behave the same way with Codex and Cursor?
• Does uninstalling leave the agent's settings files as they were?
• Is the cold-start failure limited to Windows?

The short version

• HOL Guard is an Apache-2.0 local app that allows, asks about or blocks risky agent actions through each agent's own hooks.
• In my test on Windows 10, version 3.59.0 installed in 20 seconds, put its Claude Code hooks in the global ~/.claude/settings.json, and held seven actions in about 80 seconds. A fake .env read and an rm -rf were stopped. So were git status and the project's build script.
• One early failure: the first command inspection took 64 seconds and returned NATIVE_UNAVAILABLE before the runtime was up.
• Free tier: local protection on one machine, with no account. Guard Cloud starts at $4.99 a month for syncing history across two devices.
• Gaps HOL states: background Claude Code sessions, inline Codex edits made without a tool call, and Cursor's built-in terminal outside an agent session. File writes are not among the events it sees for these three agents.
• Documentation caveats: the coverage table expired on 9 October 2026 by its own date, and it disagrees with the repository on whether Claude Code prompts are screened.
• Before you rely on it: back up your agent's settings file, turn on the approval gate, and expect to tune the default policy.

Frequently asked questions

What is HOL Guard?

HOL Guard is an open-source app from HOL (Hashgraph Online) that runs on your own machine and applies a policy to what an AI coding agent does. Through the agent's hooks it can allow, ask about or block shell commands, reads of secret-bearing files, MCP tool calls and package installs, and it keeps a local record of each decision.

Is HOL Guard free?

The local app is free and licensed under Apache-2.0. HOL's pricing page says it is free forever on one machine and needs no account. Guard Cloud is optional and paid: Solo at $4.99 a month, Pro at $15 a month and Team at $30 per seat a month, as listed on 14 November 2026.

Does HOL Guard work with Claude Code?

Yes. In a test on 14 November 2026, version 3.59.0 added its hooks to the global ~/.claude/settings.json and began reviewing a running Claude Code session at once. HOL's coverage table lists shell commands, MCP tool calls, file reads and tool results as the events Guard sees, and says background agent sessions are not covered.

Does HOL Guard stop prompt injection?

Not on its own. HOL's documentation says Guard is not a universal model-level prompt-injection filter and that runtime controls cannot guarantee a model will recognise every malicious instruction. What it can do is apply policy when an injected instruction leads to an action Guard can see.

Does HOL Guard run on Windows?

HOL's install page lists Windows as experimental, with WSL recommended. In a test on 14 November 2026, version 3.59.0 installed natively on Windows 10 with Python 3.15 and held commands in a Claude Code session. The first command inspection took 64 seconds and failed before the native runtime was up.