Prompt for installing a cross-platform Codex hook that protects critical directories from rm

codex-protect-critical-directories-hook-prompt.md

Prompt: Install a Codex hook that protects critical directories

Install a global Codex PreToolUse hook that prevents dangerous deletion of critical directories. Follow the current official documentation at https://learn.chatgpt.com/docs/hooks.

Make the implementation appropriate for the operating system and tools available on this computer. Choose the hook language, runtime, paths, and configuration format yourself. Do not assume Python, Node.js, Bash, Unix paths, or a particular home-directory location without checking the system first.

Before installing

Ask the user this question and wait for their answer:

Besides the defaults below, are there any other directories on this computer that should never be deleted? Please provide absolute paths or paths relative to your home directory.

Do not install the hook until the user answers. Add every path they identify to the permanent protection list. Normalize and validate those paths for the current platform.

Default policy

Permanently protect:

• The filesystem root
• The current user's home directory
• On macOS, the Downloads directory directly inside the user's home directory
• Every additional directory selected by the user

Also block recursive deletion of any directory directly inside the user's home directory, including arbitrary names such as ~/Documents, ~/Pictures, or ~/some-folder. This rule protects direct home-level folders without prohibiting deletion of every descendant.

Examples on Unix-like systems:

• Block rm -rf ~/Documents
• Block rm -R $HOME/Pictures/
• Block rm --recursive ${HOME}/some-folder
• Allow rm -rf ~/git/safe-repo
• Allow rm -rf ~/Downloads/archive
• Allow rm -rf ~/Documents/project/build
• Allow rm -f ~/file.txt

Installation requirements

1. Inspect the operating system, current Codex installation, available runtimes, active user-level Codex configuration, and existing hooks before making changes.
2. Preserve and merge all existing hooks and unrelated configuration. Never overwrite existing hook definitions.
3. Install the protection globally for the current user with a PreToolUse hook matching shell-command execution. Also cover supported file-edit tools such as apply_patch, Edit, and Write so an agent cannot silently remove or disable the guard.
4. Read proposed commands from the current documented hook input.
5. Protect platform-equivalent shorthand, environment-variable, and absolute forms of every protected path.
6. Recognize relevant command variants, including short and long options, combined and reordered options, -r, -R, force options, extra whitespace, common wrappers, option terminators, trailing separators, dot forms, and shell globs.
7. Permanently protected directories must be blocked whenever they are direct operands of rm, even without recursive or force flags.
8. Direct children of the home directory must be blocked when targeted by recursive rm. Do not block ordinary files directly inside home solely because they are home-level paths.
9. Parse commands conservatively. Avoid substring checks that confuse a protected directory with an ordinary descendant or confuse command text such as echo rm -rf / with an actual rm invocation. The same global hook must cover agent and subagent calls.
10. Normalize paths lexically without executing shell code. Resolve ., .., repeated separators, the hook input cwd, simple preceding cd operations, ~, $HOME, ${HOME}, $USER, $LOGNAME, $PWD, fully expanded absolute paths, quotes, and simple literal variable assignments.
11. Block recursive deletion of an ancestor of a protected directory and globs that can match one. For example, if home is /Users/example, block recursive deletion of /Users, /Users/*, and /Users/exam*.
12. Inspect absolute executable paths and common wrappers or indirection, including /bin/rm, /usr/bin/rm, sudo, env, command, xargs, eval, sh -c, bash -lc, and zsh -c.
13. Fail closed on recursive deletion commands with unresolved variables, backticks, or command substitutions. Require a literal, statically resolvable target before allowing recursive deletion.
14. Cover obvious alternate deletion mechanisms when they target protected paths, including rmdir, unlink, find -delete, find -exec, rsync --delete*, git clean, shutil.rmtree, Node filesystem removal calls, Ruby FileUtils.rm_rf, Perl remove_tree, and rimraf. Treat this list as a minimum, not an exhaustive security boundary.
15. Protect the hook script, hook configuration, and the setting that enables hooks. Block supported shell and edit-tool attempts to delete the guard or set hooks to false. Explain how the user can deliberately disable and re-trust the guard for legitimate maintenance.
16. Return the current documented PreToolUse denial response with a clear explanation of the applicable protection.
17. Do not execute any real deletion command while installing or testing. Do not create disposable directories and delete them as a test. Test only by passing inert JSON strings to the hook process.

Required test cases

On Unix-like systems, these must be blocked:

• rm /
• rm -f /
• rm -r /
• rm -R /
• rm -rf /
• rm --recursive /
• rm -fr ///
• sudo rm --recursive --force /*
• command rm -r -f /.
• rm -rf /.*
• rm ~
• rm -f $HOME
• rm -r ~/
• rm -rf "$HOME"
• The exact expanded absolute home path, such as rm -rf /Users/example
• sh -c 'rm -rf /Users/example'
• bash -lc 'rm -rf $HOME'
• zsh -c 'rm -rf /Users/example'
• rm -rf . when the hook input cwd is the home directory
• cd "$HOME" && rm -rf .
• rm -rf /Users/example/../example
• rm -rf ~/Documents/..
• /bin/rm -rf /Users/example
• printf x | xargs rm -rf /Users/example
• eval "rm -rf /Users/example"
• target="$HOME"; rm -rf "$target"
• rm -rf "$UNKNOWN_TARGET"
• find /Users/example -delete
• find /Users/example -exec rm -rf {} +
• rsync -a --delete /tmp/empty/ /Users/example/Documents/
• git clean -fdx when cwd is the home directory
• Common language-runtime deletion calls targeting the expanded home path
• Attempts to delete or disable the hook itself
• On macOS, rm -rf ~/Downloads
• rm -rf ~/Documents
• rm -R $HOME/Pictures/
• rm --recursive ${HOME}/some-folder
• Equivalent absolute forms
• Every user-selected protected directory

These should remain allowed unless the user explicitly protects them:

• rm -rf /tmp/example
• rm -rf ~/git/safe-repo
• rm -rf ~/Downloads/archive
• rm -rf ~/Documents/project/build
• rm -f ~/file.txt
• rm -rf ./build
• rm -rf node_modules
• echo rm -rf /
• git clean -fdx from inside a normal repository below home
• Read-only inspection of the hook files

Build a test matrix by passing simulated hook input directly into the hook. Never execute the embedded commands. Confirm that the implementation is executable, configuration is valid, existing hooks remain intact, hooks are enabled, and every test passes.

Report the detected platform, implementation choice, installed or modified paths, preserved configuration, complete test results, additional protected paths, limitations, restart requirements, and the current process for reviewing and trusting the hook.

Defense in depth and limitations

Inspect the current Codex sandbox and approval configuration. Warn the user if unattended agents can run with unrestricted filesystem access or approvals disabled. Recommend a workspace-write sandbox and normal approval review where practical, but do not change those global settings without explicit permission.

Explain that a user-level hook cannot provide an absolute guarantee. Current Codex documentation says PreToolUse does not intercept every execution path, including incomplete interception of newer unified execution. Encoded programs, arbitrary interpreters, MCP filesystem tools, computer-use automation, another process running as the user, or modification outside the guarded tool path may bypass lexical command inspection. Managed hooks or OS policy, least-privilege sandboxing, and tested backups provide stronger layers.

If current Codex hooks cannot reliably force an approval prompt, do not pretend they can. Use deterministic denial for the policies above. Never claim the result makes data loss impossible. Treat the hook as one carefully tested guardrail in a defense-in-depth setup.