Windows: every fresh-profile chrome launch triggers a SAM 4625 (wrong password) via Chromium's blank-password probe — can lock the user's account

Environment

• agent-browser 0.37.1, Windows 11 (26200), non-domain workstation, local SAM account with a password, Chrome-for-Testing 152.0.7977.64 (pinned build)
• Observed across GymApp QA automation: hundreds of Security event 4625s (Oct 25–27 2026), 15 account lockouts (policy 10 bad passwords / 10 min)

What happens

Every chrome launch through the agent-browser daemon produces exactly one Windows Security event 4625:

LogonType 2, Logon Process Advapi, Package Negotiate,
TargetUserName <local user>, TargetDomainName <machine>,
SubStatus 0xC000006A (wrong password), IpAddress -, KeyLength 0,
ProcessName: <pinned build>\chrome.exe (browser main process)

It fires at the launch second — for about:blank, with no HTTP at all (verified via --log-net-log: zero auth/401/Negotiate HTTP events), with a fresh empty profile, and with the auth vault empty.

Root cause

Chromium's chrome/browser/password_manager/password_manager_util_win.cc → CheckBlankPasswordWithPrefs probes whether the OS account has a blank password by calling LogonUser(username, ".", "", LOGON32_LOGON_INTERACTIVE). On a non-domain machine with a password-protected local account, that call fails and Windows logs it as a "wrong password" 4625 — the "wrong password" is the empty string. (Domain-joined machines skip the check via IsEnrolledToDomain, so this is a workstation-only bug class.)

Chromium suppresses repeat probes via a cache in <user-data-dir>/Local State:

• password_manager.os_password_blank (bool)
• password_manager.os_password_last_changed (int64, serialized as a JSON string)

Skip condition: pref_last_changed > 0 && last_changed <= pref_last_changed (last_changed derived from NetUserGetInfo password age).

agent-browser launches chrome with a fresh temp --user-data-dir per session, so that cache is never present → one 4625 per session. Ten sessions inside ten minutes lock the user's Windows account. For a QA tool that bursts sessions, this is effectively guaranteed lockouts on any non-domain Windows box.

Workaround we deployed (verified)

A transparent launch wrapper via AGENT_BROWSER_EXECUTABLE_PATH that seeds each fresh temp profile's Local State before chrome starts:

{ "password_manager": { "os_password_blank": false, "os_password_last_changed": "9223372036854775807" } }

(The value must be string-typed — a numeric literal fails Chromium's int64 pref type check and the probe still fires.) The skip condition then always holds, even after password changes. Verified PID-correlated: wrapper on → 0/0 launches probe; wrapper off → 4625 fires ~0.2 s after session start.

Suggestions

1. Seed those two Local State keys (string-typed) whenever agent-browser creates a fresh temp user-data-dir — small, contained, kills the whole bug class for Windows users.
2. Or offer per-session persistent profiles (a named-profile copy mode) so Chromium's own cache survives.
3. --disable-features does not appear to gate this probe (no runtime feature found); the Local State cache is the only verified suppression short of patching Chromium (consider an upstream crbug too — headless/automation contexts arguably shouldn't run the blank-password probe at all).

Happy to provide our full analysis and event captures. Thanks for a great tool.