Logged out everywhere, on two machines at once, is a sync clobber — not a server outage

A password manager that logs you out on two machines at the same moment is almost never the server — it is a file syncer overwriting a live browser profile while the browser is still holding it open. That single tell now has a rule behind it: a live profile never sits inside a sync folder, and the conflict files a syncer leaves behind are worth counting, because 103 of them had accumulated since February before anything surfaced.

Why did a password manager keep logging out on two machines at once?

A browser profile isn't documents. It's a set of live SQLite databases and IndexedDB stores, written continuously while the browser runs. A file-level syncer has no way to merge that: it picks a winner and renames the loser *.sync-conflict-*, and whichever machine loses gets rolled back to the other one's state. The Syncthing folder here mapped LibreWolf's profile directly between two machines, including the storage database where the Bitwarden extension keeps its vault and session.

The symptom that finally got noticed was "my Bitwarden session closed" — reported first on one machine, then on a second minutes later. Two machines logging out at once reads like a server-side event. It wasn't. By the time it was actually traced, the profile carried 103 conflict files and 94 MB of debris dating back to 2026-02-23. Six months of quiet shredding, with no symptom sharp enough to point at the cause until it happened twice in the same afternoon.

The fix draws two different lines, on purpose

A live database and a file syncer are two different models of truth, and only one of them can win. The new check treats that as a structural fact rather than an incident: any synced folder whose path matches a browser profile, a system keyring, .gnupg/.ssh, or an application vault is flagged immediately, before a single conflict file exists — because those stores can't merge by definition, they can only be overwritten.

Ordinary sync conflicts get a different treatment. Twenty-four of them already exist across normal, harmlessly-synced folders on the same machines, and most are debris nobody needs paged about. Turning every one of those into an alert would fire on day one and train everyone to ignore the channel — which is exactly the failure this fix exists to undo.

A zero-conflict risky folder is not a clean bill of health. It means the second machine hasn't booted yet.

Watching a sync client without touching its keys

The check reads folder paths straight out of Syncthing's own config file rather than calling its REST API, so it never needs — and can never be handed — an API key. And when a scan can't finish walking a folder in time, it records that count as unmeasured, not zero. A timed-out scan that reports "clean" is a confident wrong answer wearing a green light, and that's a worse outcome than an honest gap.

What shipped

Four collector cases — a risky profile present, a safe-only folder, a keyring path, and no Syncthing installed at all — plus two mutation-tested checks, deployed to the actual machine that runs the monitoring timer rather than left sitting in the repo. The last step was confirming a real heartbeat carrying the new fields reached the monitoring store, because a repo copy proves nothing about what a scheduled job is actually executing.

The 24 ordinary conflicts are still sitting there, on file as a visible count rather than individually triaged — that wasn't the job this fix was for. The job was making sure the next six months of silent shredding shows up as a number somewhere, instead of as a password manager logging itself out for no reason anyone could name.