@sixrg7734/dsh-sw-approval

classifyPyRefs -> scanWorkspaceScript approves any .py under the session cwd that (a) matches the anchor regex - satisfied by a plain comment like '# SldWorks helper' - and (b) does not contain one of the SCRIPT_DENY_TOKENS substrings. The deny list misses ordinary read/print APIs (e.g. pathlib.Path(...).read_text() and print()), and obvious names can be split ('to'+'ken'). A prompt-injected model can therefore write such a file into cwd and have the plugin return 'allowed-once' for `& ...\python.exe evil.py`, granting danger-full-access execution of model-authored code and printing arbitrary

evaluateFs allows 'write'/'edit' for every path inside the session cwd (and extraWriteRoots) with no path-shape denylist. When DSH surfaces such write approvals, a model can place persistence payloads such as .git/hooks/pre-commit, package.json postinstall scripts, .vscode/tasks.json or pipeline configs inside the workspace without human review; these execute later when the user runs git/npm/VS Code.

The anchor only needs to be present somewhere in the command, so `Get-Content <some file>; Test-Path 'D:\SolidWorks 2026\SOLIDWORKS\SLDWORKS.exe'` satisfies it while the real action is reading an unrelated file with a whitelisted cmdlet (get-content/get-childitem/select-string). The B1 deny list is name-based (password/.ssh/token/...), so files with other sensitive names (.env, config.json, browser History, *.kdbx) can be read and echoed into the session without human review.