Will It Vibe?Package-level mutable variable with no visible synchronization
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
A package-level var (not const, and not itself a mutex/atomic/channel) has no sync.Mutex, sync.RWMutex, or atomic usage nearby, in a file that also starts goroutines, so concurrent access to it can race. Heuristic: the guard may live in another file in the same package.
Why it matters
A package-level variable that goroutines can reach concurrently, with no mutex, RWMutex, or atomic operation anywhere nearby, is a classic Go data race: two goroutines reading and writing it at the same time produce undefined behavior that Go's race detector will catch in testing but that can otherwise silently corrupt values or crash the process in production, often intermittently and hard to reproduce.
How to fix it
Guard the variable with a sync.Mutex or sync.RWMutex (lock around every read and write), replace it with an atomic type (atomic.Int64, atomic.Bool, etc.) if it is a simple counter or flag, or restructure the code so only one goroutine ever owns it and others communicate with it over a channel instead of touching it directly.
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