Will It Vibe?Undocumented unsafe impl Send/Sync
Part of Security, which counts for 30% 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
unsafe impl Send/Sync for a type has no nearby `// SAFETY:` comment explaining why the type is actually safe to share or send across threads.
Why it matters
Send and Sync are unsafe traits precisely because the compiler cannot verify them: implementing them by hand is a promise that a type is actually safe to move or share across threads, and getting it wrong is a data race that the type system will never catch for you. A future maintainer changing the type's internals has no way to know which invariant the original unsafe impl depended on unless it is written down next to it.
How to fix it
Add a "// SAFETY:" comment directly above the unsafe impl explaining exactly what makes the type thread-safe (e.g. all mutable access goes through a Mutex, the raw pointer is never dereferenced outside a single owning thread). If you cannot state a real invariant, consider whether the type should implement Send/Sync at all, or whether a safe wrapper (Arc<Mutex<T>>, a channel) would avoid the manual impl entirely.
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