Windows account locks out during Antigravity 2.18.1 use as there are repeated msedge.exe authentication failures

Google Antigravity
1

## Summary

While using the **Antigravity desktop GUI** on Windows, my Windows local account became locked out. I was generating a photo and around **13:06 CEST on September 29, 2026**, and had been using Antigravity earlier in the session.

Windows Security logs show **five incorrect-password authentication attempts from `msedge.exe` between 13:02:30 and 13:09:35**, with Event **4740** recording the account lockout at **13:09:35**.

I later noticed the problem when trying to unlock Windows after **Windows+L**. Subsequent unlock failures report `0xC0000234`, meaning the account was already locked out. I had to recover access manually.

## Environment

| Component | Version / details |

| — | — |

| Windows | Windows 11 Pro **25H2**, build **26200.8875** |

| Antigravity | Desktop GUI, version **2.18.1** |

| Microsoft Edge | **154.0.4258.37** and earlier versions |

| Affected account | Local Windows account, `user` |

| Time zone | CEST (**UTC+2**) |

These are the versions I am reporting now. The exported authentication events do not establish which Edge version was running during each incident.

## Observed timeline

All times below are **September 29, 2026, CEST (UTC+2)**.

| Time | Observation | Event record ID |

| — | — | — |

| 13:02:30 | Event **4625**: incorrect-password attempt from `msedge.exe` | `3768390` |

| 13:03:41 | Event **4625**: incorrect-password attempt from `msedge.exe` | `3768467` |

| 13:04:46 | Event **4625**: incorrect-password attempt from `msedge.exe` | `3768580` |

| 13:05:21 | Event **4625**: incorrect-password attempt from `msedge.exe` | `3768655` |

| Around 13:06 | I was generating a banner in Antigravity | — |

| 13:09:35 | Event **4740**: Windows records the account lockout | `3768867` |

| 13:09:35 | Event **4625**: fifth incorrect-password attempt from `msedge.exe`, recorded at essentially the same instant | `3768868` |

| From approximately 13:39 | Unlock attempts fail because the account is already locked out (`0xC0000234`) | — |

I was not deliberately submitting these incorrect Windows passwords. The account lockout occurred before I noticed the problem at the Windows unlock screen.

## Authentication failure details

The five triggering failures share the following fields:

```text

Event ID: 4625

Status: 0xC000006D

SubStatus: 0xC000006A

LogonType: 2

LogonProcessName: Advapi

AuthenticationPackageName: Negotiate

TargetUserName: user

ProcessName: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe

Source IP / port: - / -

```

## Previous occurrence

A previous lockout on **September 23, 2026** shows the same Edge-associated pattern:

- Five `msedge.exe` incorrect-password events occurred between **10:54:35 and 10:54:44 CEST**.

- Event **4740** recorded the account lockout at **10:54:44**, record **`3590052`**.

I have not confirmed that the September 23 incident was connected to Antigravity.

## Account policy and impact

The policy captured after recovery was:

| Setting | Value |

| — | — |

| Lockout threshold | **5 failed attempts** |

| Observation window | **15 minutes** |

| Lockout duration | **Indefinite** |

The lockout prevented me from signing back into my Windows account and required manual recovery.

## Expected behavior

Using Antigravity and its browser-related features should not generate invalid authentication attempts against my Windows account or cause an account lockout.

## Related report

There is a potentially related report in Microsoft’s WebView2 tracker:

[MicrosoftEdge/WebView2Feedback #5722 — failed local authentication attempts and account lockouts]( [Problem/Bug]: WebView2 Runtime 153.0.4234.x performs a failed interactive logon (event 4625, SubStatus 0xC000006A "wrong password") as the current local user on every environment creation — can lock out Windows accounts on machines with account-lockout policies · Issue #5722 · MicrosoftEdge/WebView2Feedback · GitHub )

My retained logs also contain failures from `msedgewebview2.exe` versions **153.0.4234.32** and **153.0.4234.48**. However, the failures immediately associated with my two lockouts identify **`msedge.exe`**, so I am not assuming that the cause is identical.

## Investigation

Please investigate whether Antigravity or one of its browser integrations launches the Edge processes involved, and whether this could be related to the Microsoft report above.

I have **not** yet confirmed the parent-process relationship or established a reliable reproduction. Antigravity was in use during the September 29 incident, but that timing alone does not establish causation.

I can provide redacted Windows Security event excerpts and relevant Antigravity session logs. Please let me know which additional diagnostics would be most useful and whether there is a supported workaround.

2

Hi @x0-lf,

Welcome to the Forum,

Thank you for the detailed report and for taking the time to track down the upstream GitHub issue!

You’re right that this matches the Microsoft issue you linked (WebView2Feedback #5722). Your 4625 events are identical to that report: 0xC000006D / 0xC000006A, LogonType 2, Advapi, Negotiate, no network source. Microsoft has labeled it a tracked regression that began in the Edge/WebView2 runtime 153.0.4234.x. It occurs with any app that starts the runtime, independent of the app’s own code.

For context, Antigravity signs in with your Google Account over HTTPS and never handles or submits Windows passwords. The Antigravity desktop app is built on Electron with its own bundled Chromium and doesn’t use Edge or WebView2 for its interface. The main way Antigravity would start msedge.exe is by opening a link (for example sign-in or docs) in your default browser, if Edge is your default. That fits your Sep 23 lockout showing the same Edge pattern independently.

Since the behavior comes from the Edge/WebView2 runtime, the fix will need to come from Microsoft. In the meantime:

  • Reduce the impact of a lockout: in secpol.msc → Account Lockout Policy, consider a finite lockout duration (for example 15 minutes) instead of indefinite, so you aren’t stuck until manual recovery.
  • Identify the trigger: enable Audit Process Creation (Event 4688) or run Sysinternals Process Monitor. The next occurrence will show which parent process started the failing msedge.exe / msedgewebview2.exe.
  • Add your data upstream: your msedge.exe 154 events would be valuable on #5722, since that report currently focuses on msedgewebview2.exe.

If the process data shows Antigravity starting the Edge instance that fails, please share the redacted excerpts here and we’ll escalate with that evidence.