The author investigated how file access restrictions, specifically PreToolUse hooks and deny rules in Claude Code, function. Their PreToolUse hook, designed to exclude a file from the model's context, was unexpectedly bypassed when the cat command was used instead of the Read tool. A one-line deny rule, however, successfully blocked the cat command. This led to a series of tests to measure the reach of these restrictions across various conditions and Claude Code versions.The tests confirmed that PreToolUse hooks registered on Read did not trigger for file access via cat in Bash, while the Read tool itself was blocked. Conversely, permission deny rules did manage to block cat commands. Two control experiments revealed important nuances: a deny rule stated for a single file was mistakenly interpreted as applying to an entire directory in system messages, and a Python script execution, initially appearing to be blocked by the deny rule, was actually stopped by the auto mode classifier.The documentation clarifies that deny rules apply to Claude's built-in tools and recognized Bash commands, but not to arbitrary subprocesses like Python scripts that open files directly. For comprehensive OS-level enforcement, the sandbox is recommended. Similar experiments with an Edit hook showed it was also bypassed by sed -i, while a deny rule blocked it.However, the deny rule had its own limitations, failing to block file modifications via shell redirects, although it did catch one specific redirect. Another command for writing to a file went through without being blocked. This suggests that while deny rules are more far-reaching than hooks, they are not exhaustive, and the OS layer is the most robust solution for complete file access control. The author emphasizes testing one's own setup to identify potential gaps.