Codex Destructive Guard inspects the visible JSON input of a matching tool call only when Codex routes that call through the installed, enabled, and trusted PreToolUse hook. If invoked, it denies matching operations before that tool call executes. Malformed, incomplete, oversized, or internally uninspectable hook input fails closed. Allowed calls produce no output, and denied calls report only stable rule IDs and matched labels—not the full command or tool payload.

Full Access does not override a denial from a hook that runs. Full Access also does not turn this hook into system-wide enforcement: an untrusted, disabled, unsupported, or unrouted action is outside the boundary.

The guard:

• runs locally;
• has no third-party Python dependencies;
• makes no network requests;
• stores no telemetry or command history;
• does not read project files, credentials, or environment files.

This is a defense-in-depth guardrail, not a sandbox or backup system. It does not reliably detect ordinary output redirection, tee, an overwriting cp or mv, a generic Edit/Write overwrite, destructive behavior hidden inside an apparently safe script or compiled program, remote service side effects, browser actions, or tools that do not pass through the hook. Dynamic or novel syntax can evade a pattern, while conservative matching can cause false positives. The guard does not inspect filesystem state to infer whether a destination already exists.

The context classifier ignores dangerous words only in narrowly proven non-executable text: standalone search commands, terminal-only echo/printf, Git commit messages, and shell comments. A pipe, redirection, command/process substitution, backtick, malformed quote, or ripgrep preprocessor keeps the complete statement under strict scanning. Ripgrep hostname helper programs are treated the same way.

The documented platform contract covers Codex's Bash, apply_patch, and MCP hook matchers. Compatibility aliases are included for current clients, but users should verify the active hook in /hooks after every install or update.

Keep tested backups and version control, prefer sandboxed permission modes, separate production credentials, and review unfamiliar scripts before running them. Never use this guard as the sole control protecting production data.

Please use GitHub's private vulnerability reporting for this repository. Do not include real credentials, private commands, or sensitive file contents in the report.