How Destructive Command Guard protects Codex: intercepts dangerous Git and Shell commands

After the AI ​​programming agent can run the shell, one of the biggest risks is not writing the wrong code, but executing deletion, overwriting, or Git cleanup commands in the wrong directory. Destructive Command Guard, referred to as dcg, will be used as a tool to call pre-Hook inspection commands to intercept high-risk operations before execution.

Project address: Dicklesworthstone/destructive_command_guard

Quick Answer

dcg supports Codex CLI, Claude Code, Gemini CLI, Copilot CLI, Cursor and other tools. It is suitable as an additional line of defense, but it is not a complete sandbox: the Agent may still write dangerous operations into the script, and part of the execution path may also bypass the Hook.

Quick installation for Linux, macOS and WSL:

1

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

Remote installation scripts should be reviewed first. The installer will download the corresponding platform binary, verify the hash, and merge the supported Agent Hook configuration, rather than directly overwriting the valid existing JSON.

How it works in Codex

For Codex CLI that supports Hooks, the installer will merge the PreToolUse Hook into ~/.codex/hooks.json. After the installation is complete, open the /hooks interface of Codex once to confirm trust.

When the Agent is ready to execute a command, dcg will:

1. Parse the JSON called by the tool;
2. Extract and normalize Shell commands;
3. Quickly eliminate obviously safe commands;
4. Use rules to identify risks such as deletion, overwriting, and forced reset;
5. Return Allow, Deny or require manual confirmation.

Add pre-commit scanning to the repository

In addition to real-time Hooks, scripts and workflows to be submitted can also be scanned:

1
2
3

dcg scan install-pre-commit
dcg scan --staged
dcg scan --paths scripts/ .github/workflows/

When the team imports, it is recommended to adopt the conservative strategy of “fail with high severity” first, observe false positives, and then expand to Makefiles, Dockerfiles, and more Shell scripts.

How to verify after installation

Don’t test with a real delete command. You can have the Agent interpret an obviously dangerous simulated command and observe whether the Hook gives a blocking message before executing it. Then check:

• Whether dcg is located at PATH;
• Whether the Agent’s Hook configuration is valid JSON;
• /hooks Whether to display and trust this Hook;
• Whether the original Hook still exists;
• Whether there is no noticeable delay for normal read-only commands.

Differences in installation methods and platforms

Shell installers are available for Linux, macOS, and WSL. Native Windows should use the install.ps1 provided by the repository and do not impose Bash commands in PowerShell.

Recommendations before installation:

1. Open the script to check the download address;
2. Back up the Agent’s Hook configuration;
3. Record existing PATH;
4. Confirm the installation version and verification mechanism;
5. Run it first in a test account or test environment;
6. Check the configuration differences after installation.

Easy Mode attempts to automatically detect and configure supported Agents. It is more suitable for a team environment to use --no-configure to install only the binary first, and then manually review the Hook merge of each tool.

Complete check of Codex Hook

The new Codex CLI uses the PreToolUse Hook in ~/.codex/hooks.json. After configuration is complete:

• Confirm that JSON can be parsed normally;
• Check that the original Hooks have not been deleted;
• Open /hooks in Codex;
• Explicitly trust dcg Hook;
• Test the blocking process with non-destructive simulated requests;
• See if normal commands still pass.

If /hooks is not shown, do not assume that protection is in effect. Check Codex version, feature support and actual configuration path.

Which commands are easily intercepted?

dcg focuses on Git and Shell operations that can cause irrecoverable damage, such as recursive deletions, forced cleans, overwriting history, and dangerous commands targeting broad directories. The actual rules will be updated and the current version should prevail.

Whether a command is dangerous depends not only on the command name, but also on the parameters and targets:

1
2
3
4

rm file.tmp                 范围明确，可能允许
rm -rf /broad/path          范围宽且不可恢复，应阻止
git status                  只读
git reset --hard            会丢弃修改，应阻止或确认

Don’t break a command into more subtle steps to get around false positives. Rules should be revised, use clear goals, or be left to human execution.

How Scan pattern is used in code bases

The real-time Hook protects the command that the Agent is currently preparing to execute, and dcg scan checks the possible execution of Shell fragments in the repository, including scripts, CI workflows, Dockerfiles, and Makefiles.

First time import suggestions:

1

dcg scan --staged --fail-on error

Only let high-confidence critical issues block submissions. After observing for a period of time, expand the scope to:

1

dcg scan --paths scripts/ .github/workflows/

Don’t set all Warnings as CI failures on day one, otherwise false positives will prompt the team to shut down the tool directly.

Responsibilities of pre-commit Hook and CI

Local pre-commit

The feedback is fast, suitable for discovering new dangerous commands before submission, but users can use --no-verify to bypass it, or they may not have Hook installed.

CI Scan

Uniform execution by the repository is more suitable for forming mandatory rules. The dcg version should be fixed in CI, the download should be verified, and only this difference or path should be scanned to avoid the results changing with the upstream.

Agent PreToolUse

Block before command execution, protecting the current workspace. It does not replace CI’s ongoing inspection of the repository’s contents.

The three solutions have different time points and can be used at the same time.

How to manage Allowlist

Some projects do require cleaning the build directory or resetting the staging environment. Rather than shutting down the entire dcg, create minimal exceptions for well-scoped, verifiable commands:

• Only allow specific temporary directories within the project;
• Do not use environment variables to splice broad root paths;
• First parse and output the absolute path;
• No permanent exceptions to production catalogs;
• Exceptions into version control and code review;
• Regularly delete rules that are no longer needed.

The goal of security exceptions is to reduce false positives, not to allow the Agent to gain a general bypass.

How to test without destroying data

Do not perform git reset --hard or recursive deletion on the real repository. You can use a temporary test repository and dummy command parameters to observe the parsing output of dcg. Testing includes at least:

1. Ordinary read-only commands are allowed;
2. Obvious dangerous orders are blocked;
3. Cleanup commands with clear target scope are processed as expected;
4. Illegal Hook JSON will not be silently released;
5. Enter manual confirmation when it times out or cannot be judged;
6. The original Hook still works normally.

Why Hook is not a complete sandbox

A Hook can only inspect tool calls it sees. The following paths may still be bypassed:

• Agent writes the script and then executes it by other processes;
• The IDE or plug-in uses a terminal interface that is not connected;
• The program deletes cloud resources through API;
• Commands in the container affect the mounted host directory;
• Operate on another machine after the credentials are compromised;
• User actively uses --no-verify.

So OS permissions, container mounts, cloud IAM, backups, and approvals still have to be present.

Update and rollback

Available:

1

dcg update

Teams should not automatically update rules on all development machines without a plan. First verify the false positives and compatibility of the new version in the test repository, and then upgrade it in batches. Rollback requires retaining the old version number and configuration backup.

Troubleshooting Matrix

What it doesn’t solve

Hooks are not operating system permission boundaries. The official also reminds that the Agent can write the script first and then execute it, and some of the unified execution paths of the Codex may not be fully intercepted. Therefore, cooperation is still required:

• Non-administrator account;
• Limit the working directory;
• Git branch or working tree;
• Important data backup;
• Manual approval of delete and push operations;
• Container or virtual machine isolation.

FAQ

Will the installer overwrite my Hooks?

The official implementation will try to merge; if the existing JSON is invalid or has an abnormal structure, the original file will be retained and an error will be reported. The configuration should still be backed up before installation.

Why are dangerous commands not blocked?

Check whether the command takes a supported Hook path. If the Agent encapsulates the operation into a script, an application-internal tool, or an execution interface that is not covered, dcg may not see the final command.

Will dcg significantly slow down each command?

The project is designed as a fast hook and sets an absolute upper limit on processing time. Actual latency should still be measured on your own terminal and ruleset; if slowdown is noticeable, check logs and other hooks.

Can it be installed only on CI and not on the development machine?

The contents of the repository can be scanned, but the local Agent cannot intercept the command before it is actually executed. It is still recommended to configure PreToolUse Hook in high-privilege Agent environments.

How to handle false interception in emergency situations?

Confirm command purpose and recoverability before executing it manually or creating minimal temporary exceptions. Do not allow the Agent to automatically find bypasses.

Summary

dcg can reduce the probability of Agent accidentally executing dangerous Git and Shell commands, especially suitable for environments that already allow Codex or Claude Code to run terminals. But it should be regarded as a safety belt, not a safe; the truly reliable solution is still the combination of least privileges, directory isolation, backup and manual approval.