[Bug]: Integrated browser reaches Google unsupported-browser page after sign-in and 2FA

[bionboy]

Before submitting

• I searched existing issues and did not find the same failure.
• I included the observed flow and environment needed to investigate.

Area

apps/desktop — integrated browser preview

Summary

• Google Account rejects the integrated browser after sign-in and phone-code 2FA. The browser reaches Google's unsupported-browser page instead of the account settings page.
• This blocks continuing Google Account / Google Cloud setup inside the browser shared with the coding agent.

Steps to reproduce

1. Open Google Account / Google Cloud in T3 Code's integrated browser.
2. Sign in to Google.
3. Complete the 2FA challenge using a code from a phone.
4. Observe the Account settings tab after authentication.

• Observed once in an existing session. A clean-profile reproduction has not been attempted, and the exact initial Google entry URL was not recorded.
• Google Cloud project setup and a Google OAuth consent callback had succeeded earlier in the same browser. This is not a claim that all Google authentication always fails.

Expected behavior

• Google Account settings should load after sign-in and 2FA when the integrated browser is supported.
• If Google disallows the embedded browser, T3 should explain that limitation and provide a clear external-browser handoff rather than leaving the user at a browser-update dead end.

Actual behavior

• The Account settings tab navigates to https://myaccount.google.com/not-supported?pli=1.
• Google displays: “Your browser is not supported anymore. Please update to a more recent one.”
• The page offers download links for Chrome, Firefox, Edge, and Safari.
• The screenshot shows adjacent Google Cloud Plat... and Account settings... tabs in the integrated browser.

Impact

Major degradation or frequent failure — the affected Google Account workflow cannot continue inside the integrated browser.

Version or commit

• Installed desktop app: T3 Code (Nightly) 0.0.45-nightly.20261001.2539.
• Version collected from the installed app's Info.plist; both CFBundleShortVersionString and CFBundleVersion match.
• Bundle identifier: com.t3tools.t3code.

Environment

• macOS 26.3.1, arm64.
• T3 desktop integrated browser, used collaboratively with a Codex / GPT-6.1-Sol agent.
• Browser user agent, embedded Chromium/Electron version, and Google network/console logs were not collected.

Logs or stack traces

• No stack trace was captured for the unsupported-browser page.
• Separate browser automation symptoms were observed earlier in the session; a shared cause is unproven:
  • A mobile preview tab (tab_5, iPhone SE preset, 375 × 667) returned available:false, visible:false, url:null, title:null, loading:false from preview_status.
  • Repeated preview_open attempts returned Preview automation open timed out after 15000ms.
  • preview_snapshot sometimes returned generic automation errors.
  • preview_click sometimes reported success without a visible action, while a DOM click through preview_evaluate sometimes worked.
  • Research tabs later redirected to Google login and the preview session became unavailable. The relationship to the reported 2FA event has not been established.

Screenshots, recordings, or supporting files

• A screenshot was captured and reviewed. It shows the exact URL, message, browser download choices, and adjacent tabs described above, with no credentials or authentication codes visible.
• The screenshot has not been uploaded: this ticket was filed through the GitHub CLI, which does not provide an issue-attachment upload operation. The original PNG is retained locally for manual attachment.

Workaround

• Suggested: start the affected Google workflow in an up-to-date external Safari or Chrome browser. This has not yet been verified for this session.
• Google's supported-browser guidance and embedded-browser sign-in policy are useful context. The screenshot alone does not distinguish an outdated/incorrect user agent from an embedded-browser restriction or another compatibility problem.

Related issue

• [Bug]: Integrated browser preview blocks OAuth popup authentication #6561 concerned OAuth popup blocking before authentication (auth/popup-blocked). This report reaches Google sign-in and 2FA, then displays the unsupported-browser page; it appears to be a different failure mode.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the careful write-up, @bionboy, especially the note that the earlier Google Cloud setup and OAuth callback worked. That detail helped narrow this down.

This looks like Google rejecting embedded browsers, not an outdated engine. Nightly 0.0.45-nightly.20261001.2539 ships Electron 44.4.2, which is Chromium 152, a current engine. The preview deliberately keeps Electron's native user agent, including the T3Code(Alpha)/… and Electron/… tokens. Rewriting it broke Cloudflare Turnstile and caused the login loop in closed issue #5002. Google Account doesn't treat that user agent as a supported browser, and myaccount.google.com/not-supported is its unsupported-browser page. Google's supported-browser guidance says it blocks sign-in from browsers embedded in other apps. Sign-in and 2FA can still pass while Account settings applies a stricter check, which fits what you saw. It's also a different failure from the OAuth popup block in closed issue #6561.

Spoofing a Chrome user agent probably isn't the answer. Google asks developers not to do that, and it would likely bring back the Turnstile loop. Your other suggestion, explaining the limitation and offering a clear hand-off to an external browser, is a reasonable improvement. A maintainer will decide whether to take that on.

Workaround: start Google Account or Google Cloud setup in Safari or Chrome. You can hover the preview address bar and use Open in system browser to open the current URL outside the app. The preview's cookies don't carry over, so you'll need to sign in again there.

The preview automation timeouts and preview_status results from earlier in that session haven't been tied to this. If they still happen in a clean session, please open a separate issue for them.

[juliusmarminge]

This report predates #15328, but one known cause of Google rejecting the in-app browser was fixed in #16939: cross-site sign-in frames stayed paused in desktop tabs the server drives. Google sign-in now works in a desktop tab on a build with that fix. If you still reach the unsupported-browser page after 2FA on a newer build, please say so here with the URL you started from.