Will It Vibe?Unquoted variable in a destructive 'rm -rf'
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
rm -rf $VAR (no quotes) is subject to word-splitting and globbing: if VAR is empty or unset, the argument can vanish or, when it prefixes a path like $VAR/*, expand into something like /* and delete far more than intended. Quoting the expansion ("$VAR") makes rm -rf operate on exactly the one path you meant.
Why it matters
rm -rf $VAR without quotes lets the shell word-split and glob the expansion before rm ever sees it. If VAR is empty or unset, the argument can disappear entirely or, worse, when it prefixes a path like $VAR/*, the expansion can collapse into something like /* and delete far more than the script intended. This exact shape of bug has wiped out entire home directories and production volumes in real incidents.
How to fix it
Quote every variable expansion in a destructive command: rm -rf "$VAR" or rm -rf "${VAR:?VAR is not set}". The :? form makes the script abort with an error message instead of silently deleting the wrong thing if the variable is ever empty. Apply the same quoting habit to every other destructive command (mv, cp -r, find -delete) that takes a variable path.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo