Google never recognizes a persistent profile as familiar and triggers CAPTCHA/2FA after IP changes

Summary

I am experiencing a persistent trust and familiarity issue when using CloakBrowser with Google.

I have been using the same browser profile and the same seed for several consecutive days. Despite keeping the profile consistent, Google does not appear to recognize it as a familiar or trusted browser.

This is not only a general CAPTCHA issue. Google appears to treat the browser as a possible automated or suspicious client:

• The browser is never recognized as a familiar browser.
• When I change the public IP address, Google becomes suspicious again.
• When I access security-related sections of my Google Account, Google may require a CAPTCHA.
• Even after completing the CAPTCHA, access can still be denied.
• Google then displays a message telling me to use a familiar IP address or a familiar device to access the account.
• Occasionally, Google reports a new sign-in and requires two-factor authentication, even though I am still using the same browser profile. It appears that changing the IP may be treated as a new sign-in.

Important observation

In Google's list of signed-in devices, I still see only one browser: the current browser I am using. I do not see multiple browser entries or an additional device that would explain the repeated new-device treatment.

Therefore, the behavior seems inconsistent:

• Google's device list shows only the current browser.
• The same profile and seed are used continuously for multiple days.
• However, Google does not treat the browser as familiar.
• An IP change can trigger bot suspicion, CAPTCHA challenges, access denial, a new-sign-in notification, and two-factor authentication.

Environment

• Host OS: Windows x64 desktop.
• Application: Antidetect Browser Manager v0.1.0.
• Runtime: Node.js v20.19.6; npm 10.8.2.
• CloakBrowser Node.js package: v0.5.10.
• Active CloakBrowser browser build shown in the manager: Chromium 151.0.7922.108.6 (Pro).
• CLOAKBROWSER_RELEASE_CHANNEL=preview is present in the project environment.
• Browser mode: headed; the profile is not launched headlessly.
• Profile mode: persistent. The same profile user-data-dir is reused across browser restarts.
• Fingerprint: one fixed seed is reused across sessions.
• Launch path: the manager starts CloakBrowser's patched Chromium directly and enables a local CDP endpoint using a dynamically allocated remote-debugging port.
• Launch identity flags are supplied by the manager from the profile fields, including the fingerprint seed and, when configured, timezone, locale/language, and WebRTC IP.
• No account identifiers, fingerprint seed value, credentials, proxy provider, proxy endpoint, or other proxy details are included here for privacy. The only network change relevant to this report is that the public IP is changed between sessions.

Reproduction sequence

1. Launch the same persistent profile.
2. Use the same profile and the same seed for multiple consecutive days.
3. Change the public IP address and start the same profile again.
4. Open security-related sections of the same Google Account.
5. Observe the CAPTCHA, continued access denial after completing it, and the request to use a familiar IP address or familiar device.
6. Observe that Google may report a new sign-in and request two-factor authentication.
7. Check Google's signed-in devices list; it still shows only one browser, the current browser.

Actual behavior

1. I use one persistent CloakBrowser profile with the same seed for multiple days.
2. Google still does not establish or retain familiar-browser status for that profile.
3. After changing the public IP address, Google treats the session as suspicious again.
4. Accessing security-related account sections can trigger a CAPTCHA.
5. Completing the CAPTCHA does not always restore access; Google may continue to deny the request.
6. Google asks me to use a familiar IP address or familiar device.
7. Sometimes Google reports a new sign-in and requests two-factor authentication, even though the same profile and browser are being used.
8. Google's device list still contains only one browser, which is the current one.

Expected behavior

I understand that Google may evaluate IP reputation and other risk signals independently. I also understand that changing an IP address can increase the account's risk score.

However, I expected a persistent profile to retain at least some familiarity when its browser identity and stored profile data remain consistent. I also expected the same profile to be represented consistently in Google's device and sign-in history.

Questions

1. Which browser identity signals are intended to remain stable for a CloakBrowser profile, and which signals are regenerated or reset at launch?
2. Can changing the public IP invalidate the profile's familiar-browser status because of a mismatch involving cookies, storage, device identifiers, TLS characteristics, client hints, timezone, locale, WebRTC, DNS, or geolocation?
3. Are there known limitations that prevent Google from recognizing a CloakBrowser profile as a familiar browser, even when the same profile and seed are used for multiple days?
4. Could a signal that is not being persisted consistently cause Google to treat the browser as a bot or an unfamiliar device?
5. Why might Google show only one browser in the signed-in devices list while still reporting new sign-ins and requesting two-factor authentication after an IP change?
6. Is this behavior expected because of Google's own risk-scoring system, or could it indicate a CloakBrowser profile-persistence or identity-consistency issue?
7. What profile and launch settings, logs, or diagnostic data should I provide to distinguish a CloakBrowser issue from Google's risk assessment?

I am looking for an explanation of the expected behavior and supported configuration, rather than a way to bypass Google's security checks. I can provide additional non-sensitive diagnostics if needed.