False positives block legitimate cleanup operations and string literals in gh commands

[McNerve]

Problem

Safety Net's built-in rules block legitimate cleanup operations from tools like gstack that use standard Unix patterns for session/temp file management.

Blocked commands

1. find with -delete flag — gstack's skill preamble runs find ~/.gstack/sessions -mmin +120 -type f with the delete flag to clean up stale session files. Safety Net blocks this with: "find -delete permanently removes files. Use -print first to preview."

2. rm -rf outside cwd — Commands like rm -rf /tmp/gstack-test-dir are blocked with: "rm -rf in home directory is dangerous." This triggers when cwd is ~, even though the target is /tmp/.

Why these are false positives

• The find cleanup is scoped to ~/.gstack/sessions/ with -mmin +120 (files older than 2 hours). This is safe, targeted cleanup.
• /tmp/ is designed for ephemeral files. Blocking rm -rf /tmp/<specific-dir> is overly conservative.
• The string-matching also triggers on gh issue create body text that merely mentions the blocked pattern — blocking the creation of this very issue.

Current workaround

Skip the cleanup commands or ask the user to run them manually. Works but adds friction.

Suggested fix

Consider one of:

• Allow find with delete flag when scoped to user config directories (~/.gstack/, ~/.cache/, etc.)
• Allow rm -rf targeting /tmp/ regardless of cwd
• Support an allowlist mechanism for trusted paths in custom rules (expanding on the closed Feature: User-configurable custom rules via config file #4)
• Don't pattern-match blocked commands inside string literals / heredocs (the body of a gh issue create is not a shell command)

Environment

• Safety Net v0.8.1
• macOS (Darwin 25.4.0)
• Triggered via gstack skill preamble in Claude Code

[kenryu42]

Thanks for reporting this.

The rm -rf false positive you mentioned, where the cwd is ~ but the target is under /tmp, has already been fixed in v0.8.2.

For the find -delete case, I’m currently redesigning the custom rules feature and plan to include an allow/trusted path mechanism so safe, scoped cleanup paths can be configured explicitly.

I’ll keep this issue open and post updates here as that work lands.