One command adds a shell guard to Claude Code, Cursor, Codex, Gemini CLI and Copilot

The short answer

Run npx deedglass protect. It looks for Claude Code, Cursor, Codex CLI, Gemini CLI and GitHub Copilot CLI in your home directory, prints one plan naming each file it will change, and after you say yes adds Deedglass’s shell guard as each agent’s before-a-command hook.¹ From then on, a command that would destroy a database, a volume or infrastructure stops for a decision before it runs. It is a second check, not a sandbox.

The rest of this post is what it actually wrote on a test machine, what each agent does with the answer, and where the approach stops.

What the plan looks like

We ran deedglass 0.13.0 against a scratch home directory that held an empty config folder for each of the five agents. The dry run writes nothing:¹

Code What the screen or file shows, copied as is.

$ npx deedglass@0.13.0 protect --dry-run
deedglass protect  5 of 5 agents found · dry run

  Claude Code     → adds the guard (PreToolUse)
                    ~/.claude/settings.json
  Cursor          → adds the guard (beforeShellExecution)
                    ~/.cursor/hooks.json
  Codex CLI       → adds the guard (PreToolUse)
                    ~/.codex/hooks.json
  Gemini CLI      → adds the guard (BeforeTool)
                    ~/.gemini/settings.json
  GitHub Copilot  → adds the guard (preToolUse)
                    ~/.copilot/hooks/deedglass.json

  hook  npx -y deedglass@0.13.0 guard shell

Dry run: nothing was written. 5 files would change.

Without --dry-run it shows the same plan and waits for y. It backs up every file first, and only adds: it merges into the JSON already there and keeps your own hooks.¹ A second run on the same machine printed “already has the guard” for all five and “Nothing to change.”¹

--client claude-code,cursor limits it to some agents, and --project also writes into the current repository’s folders, so the hook travels with the code.¹

The five files it writes

Each agent names the event, the matcher and the timeout differently. This table is taken from the files protect wrote in our run.¹

Here is the Codex entry, the one with the most moving parts:

Code Data in JSON, the format software uses to pass records and settings.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "npx -y deedglass@0.13.0 guard shell --client codex",
            "timeout": 10,
            "statusMessage": "Deedglass shell guard"
          }
        ]
      }
    ]
  }
}

The hook pins the version it was installed with, so an upgrade elsewhere doesn’t change what runs inside your agent. If you installed the binary rather than using npx, the hook starts it by its path instead.¹

In 0.13.0 the guard was one catalog: 55 rows, 53 command shapes and 2 read limits.² In 0.14.1 it has 58 rows, 56 command shapes and 2 read limits, each with a primary source and the date it was checked.² Run npx deedglass guard shell --list to read it.

Ask in three agents, deny in two

The guard answers “ask” when part of a command matches the catalog. Not every agent can ask.

• Claude Code, Cursor and Copilot CLI show you the command and the reason, and wait.¹
• Codex CLI parses an “ask” answer but doesn’t support it yet: it marks the hook as failed and runs the command.³ So with Codex the guard denies instead.
• Gemini CLI hook decisions are allow and deny; there is no ask.⁶ There, too, it denies and shows why.
• Copilot’s cloud agent, and Copilot CLI in autopilot, treat ask as deny.⁵

Protect prints this at the end of the run, so nobody is surprised later:

Code What the screen or file shows, copied as is.

✓ Added the guard to 5 files. Backups are in ~/.deedglass/protect/20261027T095409.469184000Z.
  • Codex runs the hook after you trust it with /hooks. It can't ask, so the guard denies.
  • Gemini CLI can't ask, so the guard denies and shows why.

That Codex line matters. A non-managed Codex hook runs only after you review and trust it with /hooks.³ Until you do, Codex has the file but not the guard.

To see the answer a command would get without starting an agent, give the guard the command directly. Exit 1 means it would stop:²

Code What the screen or file shows, copied as is.

$ npx deedglass@0.13.0 guard shell --no-files --command 'terraform destroy'
Deedglass asks first: terraform destroy destroys every resource the configuration manages.
  terraform-destroy  terraform destroy destroys every resource the configuration manages

When the guard can’t run

Every one of these hooks has a failure mode, and you should know which way it falls. If the guard can’t run at all (no deedglass on the PATH, Windows without Git Bash, a timeout) the command goes ahead unchecked.² The agents agree on this more than you might expect:

• Cursor’s failClosed defaults to false, so a crash, a timeout or a non-zero exit other than 2 lets the action through.⁴
• Copilot hook timeouts fail open for every event, including preToolUse.⁵
• Copilot’s preToolUse is the exception for errors: a non-zero exit other than 2 denies the call.⁵

That last rule is why the Copilot entry protect wrote ends in || true:

Code Data in JSON, the format software uses to pass records and settings.

"bash": "npx -y deedglass@0.13.0 guard shell --client copilot || true"

Without it, a machine where npx can’t start would deny every tool call Copilot makes. With it, a broken guard fails open like the others. That is a choice, and it is the same trade the other four agents make by default: a guard that can’t answer doesn’t freeze your editor.

Practical advice: run the dry run on a new laptop, then run one guarded command through each agent you use, before trusting it.

Undo, and rolling it out to a team

deedglass protect --undo puts each file back byte for byte, or, if you edited the file since, takes out only the guard.¹ In our run it printed one line per agent and “Put back 5 files.”¹

For a team, two approaches work:

1. Per developer. Each person runs npx deedglass protect. It touches only their home directory.
2. Per repository. Run npx deedglass protect --project once and commit the files it writes in the repository, so every clone gets the hook. Codex still loads a project’s hooks only when that project is trusted.³

If you use the Deedglass plugin for Claude Code, its shell guard is already on by default from v0.12.0; DEEDGLASS_SHELL_GUARD=off turns it off.²

After a successful run, protect prints a README badge that links to the free checker.¹ The badge says the hook was installed. It doesn’t say the repository is safe, and you shouldn’t read it that way.

What it won’t catch

A pre-command hook reads text. A value known only at run time, such as a variable, an alias, a Makefile target, encoded text, code an interpreter runs or a database reached over HTTP, passes untouched.² We ran a set of commands through 0.14.1 to show the edges. These got “Nothing to ask about”:²

Three commands that 0.13.0 let through now get an ask in 0.14.1: docker compose down -v, helm uninstall and mongosh --eval with dropDatabase() or a collection’s drop().²²

So treat protect as one layer. The others are a database role that can’t drop tables, cloud credentials that can’t delete, and backups you have restored at least once. The checklist before an agent touches production puts them in order, and how each agent’s hooks differ goes deeper on the formats. If you’d rather write your own hook, start from the 14-line Claude Code version and the glossary entry on the PreToolUse hook.

To try it without changing anything, run npx deedglass protect --dry-run. It prints the plan and writes nothing. To grade what an agent can reach on your own machine, run npx deedglass scan (what the grade means). To watch the checks without installing anything, open the playground.

Written with AI assistance and checked against our claims register.