Postmortem: How I messed up my Chrome login state and extensions — don’t remote-debug on your real Profile

General
,
1

This is a warning post for myself. While debugging a Chrome extension, I took my real everyday Chrome Profile and used it for extension sync, and ended up messing up my login state and extension state.

Conclusion first: this wasn’t “Chrome randomly glitching out”—it was a bad automation operation.

Facts confirmed from the local session

  • I first executed a command to force-quit Chrome, which is basically the same as killing the browser process that was in use.
  • Then I restarted my real Chrome and pointed it directly at the default Profile in my real user-data directory.
  • The launch arguments included a remote debugging port and --disable-sync.
  • The target page was the extension settings page for All API Hub.
  • The local helper code originally had a safeguard to “exit if Chrome is already running,” but before doing the operation I force-killed Chrome first—effectively bypassing that safeguard.

Why it broke

Chrome’s login state, extension registration, sync state, and some preferences are all tightly bound to the real user-data directory.
When I did all of the following to my real Profile at the same time:

  • force-killed a running Chrome
  • took over the real Profile via remote debugging
  • added --disable-sync on the real Profile

…the result was mixing my “everyday browser state” together with “temporary automation actions.”
This kind of operation won’t necessarily wipe the underlying data completely, but it can easily scramble the surface-level state, for example:

  • Google account appears to be signed out
  • extensions temporarily disappear or get re-registered
  • extension settings / sync state roll back
  • some sites’ login state, and window/session restore behavior become abnormal

How recovery went this time

Afterward, by signing back into Chrome and waiting for extensions and settings to resync, core functionality basically recovered.
That also shows that a lot of the underlying data wasn’t “completely gone”—it was more like I personally threw the Chrome account layer, sync layer, and extension registration layer into chaos.
But “it can recover” doesn’t mean the approach was fine, because the confusion and uncertainty in the middle were real.

Results from checking historical sessions

I went back through my local archives.
The conclusion:

  • For this incident on 2026-04-25, there’s a complete and unambiguous chain of evidence.
  • As for whether the same kind of “force-kill Chrome + take over the real Default Profile” accident happened earlier, I haven’t found evidence with the same level of certainty in my local archives. I can only say I may have had a similar feeling before, but this time is one that can be clearly confirmed.

Hard rules going forward

From now on, whenever Chrome automation is involved, I will follow these rules without exception:

  1. Never automate against my real everyday Chrome Profile.
  2. Never force-kill a running Chrome just to take over the browser.
  3. Never use --disable-sync, remote debugging, or temporary experimental flags on a real Profile.
  4. When debugging extensions, only use a separate temporary user-data-dir or a dedicated test Profile.
  5. When extension account data needs to be written, prefer import/export, storage-layer writes, or dedicated APIs; no more hijacking real browser sessions.
  6. Before any browser-level experiments, back up Local State, Preferences, Secure Preferences, and Sessions.

The essence of this isn’t that Chrome is unstable—it’s that I treated “production” like “experimental.”
Writing it down so I don’t repeat it next time.