Will It Vibe?os.Exit called after a defer in the same function
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
os.Exit terminates the process immediately without running any deferred calls, so a defer registered earlier in the same function for cleanup (closing a file, releasing a lock, flushing a buffer) never runs.
Why it matters
os.Exit terminates the process immediately at the operating-system level; it does not run any function currently deferred, anywhere on the call stack. A defer earlier in the same function that closes a file, releases a lock, flushes a log buffer, or rolls back a transaction is silently skipped, so exiting this way can leave a partially-written file, a stuck lock, or an uncommitted transaction that a normal return would have cleaned up.
How to fix it
Return an error (or a specific exit code) from the function instead of calling os.Exit directly, and let main() be the only place that calls os.Exit, after every other function has already returned and its defers have run. If you specifically need cleanup to happen even on a fatal error, run it explicitly before calling os.Exit rather than relying on defer.
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