Claude Code approved itself: Guard paused the self-click

Claude Code approved itself: Guard paused the self-click

Claude Code hit a warning, then ran hol-guard approvals approve on itself. HOL Guard froze it. Inbox: Allow just this once or Keep blocked.

2 min read531 words
Contents

You were in Claude Code. It hit a warning on a dangerous command, then ran hol-guard approvals approve so it could clear the pause itself. If that worked, you would still see a green Approved screen. You never said yes. The same session that tripped Guard would have rubber-stamped the decision.

HOL Guard froze the self-approve. You still pick Allow just this once or Keep blocked. Until you Allow just this once, Claude Code has not approved its own pending action.

HOL Guard Inbox: PAUSED ACTION on hol-guard approvals approve from Claude Code, Allow just this once and Keep blocked
Local Inbox review when Claude Code queued hol-guard approvals approve. Card is Needs review with Allow just this once and Keep blocked.
Close-up of Allow just this once (green) and Keep blocked buttons on HOL Guard review card
Button labels on the live review card: Allow just this once, Keep blocked. Scope defaults to a one-time allow for this exact action.

Keep blocked leaves the self-authorize stopped. The receipt stays on your machine.

Why an agent approving itself breaks Guard

Guard's job is a human decision between detection and exec. If the same agent session can clear that decision, every other pause becomes theater. Required protection exists so hot auto-approve settings cannot quietly demote Guard into a logger while the chrome still looks green.

You approving from Inbox, or typing hol-guard approvals in a terminal you own, stays normal work. The Extension targets commands that authorize or weaken Guard from inside the reviewed process.

What the catalog maps

Required Guard self-protection (command.guard-self-protection, v1.0.0, high). Catalog default: review. One operation: Guard self-authorization (command.guard-self-protection.self-authorization). Identifies commands that attempt to approve or weaken their own Guard decision. Catalog example: hol-guard approvals approve.

A workspace can still tighten or (where policy allows) loosen floors unless a managed-restrictive Control Set pins the permission. Catalog default is not your fleet policy. Treat changes to this permission as integrity work, not convenience tuning.

Out of scope

command.guard-self-protection does not cover:

  • You approving a paused action from Inbox or a terminal you typed yourself.
  • Credential send or file upload via curl: command.data-protection.
  • Decode-and-execute chains: command.encoded-execution.
  • Package installs and one-shots: Package Firewall Extensions.
  • Chat nagging you to click Allow just this once. Mapped ops are commands that authorize or weaken Guard state.

One check that does not approve anything

command test and command explain do not execute the command, create an approval, or write a receipt.

hol-guard command test 'hol-guard approvals approve'
hol-guard command explain 'hol-guard approvals approve'
hol-guard command controls show command.guard-self-protection
hol-guard command extensions

After an upgrade, run the test before you trust muscle memory. If test says unrecognized, confirm the Extension is current and posture is not Watch.

Keep the human decision

You can still approve from Inbox or a terminal you typed. This Extension is for the agent trying to clear Guard from inside the same session.

For a team floor that laptops cannot weaken under auto-approve, pin a managed-restrictive Control Set on this Extension's permission ID.

If you meant to clear a pending item yourself, do it from Inbox or a terminal session you own. If Claude Code proposed hol-guard approvals approve, Keep blocked and ask why it needed to skip you. Receipt stays local. Cloud sync is optional and does not carry the raw command.

Background: HOL Guard 3.0.

Continue reading

All posts