作者调查了文件访问限制在 Claude Code 中的运作机制，特别是 PreToolUse hooks 和 deny rules。其设计的 PreToolUse hook 旨在将文件排除在模型上下文之外，但当使用 cat 命令而非 Read 工具时，该 hook 被意外绕过。然而，一条单行 deny rule 成功阻止了 cat 命令。由此引发了一系列测试，以衡量这些限制在不同条件和 Claude Code 版本中的覆盖范围。测试证实，注册在 Read 上的 PreToolUse hooks 不会触发 Bash 中通过 cat 进行的文件访问，而 Read 工具本身已被阻止。相反，权限 deny rules 确实能够阻止 cat 命令。两项对照实验揭示了重要细节：针对单个文件声明的 deny rule 在系统消息中被错误地解释为适用于整个目录；而一个 Python 脚本执行看似被 deny rule 阻止，实则是由自动模式分类器（auto mode classifier）终止的。文档阐明，deny rules 适用于 Claude 的内置工具和已识别的 Bash 命令，但不适用于直接打开文件的任意子进程（如 Python 脚本）。为实现全面的操作系统级强制控制，建议使用沙箱（sandbox）。类似的 Edit hook 实验也显示，其被 sed -i 绕过，而 deny rule 则成功阻止了该命令。然而，deny rule 自身也存在局限性：它无法阻止通过 shell 重定向进行的文件修改，尽管它确实捕获了某一种特定的重定向。另一条用于写入文件的命令则未被阻止。这表明，虽然 deny rules 比 hooks 具有更广泛的覆盖范围，但并非 exhaustive；操作系统层是实现完整文件访问控制的最稳健方案。作者强调，应测试自身环境以识别潜在漏洞。