Claude Code 2.1.296: relative deny rules fail, absolute paths hold

The test grew out of a practical setup: the author runs Claude Code in two working folders and wanted to keep one from modifying the other, so he wrote Edit(../shared/partner/**) into company/.claude/settings.json and assumed it was protected. He only noticed the rule was not holding when he was trying something else and saw the file change anyway. Against the official Configure permissions document, which lists //path, ~/path, /path and path or ./path as the supported forms, the ../ style simply is not among them, and in his run it failed without warning. Writing the rule as a Write(...) rule instead produced a startup warning telling him that Write(path) is not used for file permission checks and that Edit(path) should be used. Across his runs, the absolute-path rule did block the Write tool, Edit tool and Bash echo >, but not a node script run through an auto-allowed Bash. In a separate check, denying .env with Read(./.env) stopped the Read tool and cat .env, yet a node -e script could still read it under auto-allowed Bash. The author notes Claude Code's documentation already states that Read and Edit deny rules do not cover files opened by Python or Node scripts, and that sandboxing is the way to enforce this at the OS level. He suggests running Claude Code under a separate Windows user without file permissions, or in a virtual machine or container, and keeping production keys off the same machine.