On current main the Linux server preview reaches WhatsApp's account-linking page (QR code), with the reduced Chrome 154 user agent and matching client hints. The desktop app deliberately keeps its native Electron identity (it carries T3CodeNightly and Electron tokens, kept because of earlier Turnstile regressions), so this does not show your macOS case is fixed. Could you retry the latest nightly with a fresh browser profile and share navigator.userAgent and navigator.userAgentData?.brands from the affected page, plus whether the warning still shows?
[Bug]: WhatsApp Web rejects the integrated browser despite Chromium 152#22444
Before submitting
- I searched existing issues and did not find a duplicate for WhatsApp's unsupported-browser page.
- I included the observed flow and environment needed to investigate.
Area
apps/desktop — integrated browser preview
Steps to reproduce
- Open the official T3 Code Nightly desktop app, version
0.1.1-nightly.20261017.3238, on macOS. - Open
https://web.whatsapp.com/in the integrated Browser using the Default profile. - Observe the page before reaching account linking or the chat list.
This was reproduced in multiple integrated tabs during one session on 20 October 2026. A clean-profile reproduction has not been attempted.
Expected behavior
WhatsApp Web should reach account linking or the chat list if the embedded browser is compatible. If WhatsApp disallows this browser, T3 should explain the limitation and offer a clear external-browser handoff.
Actual behavior
WhatsApp displays:
WhatsApp works with Google Chrome 100+
It offers browser-download links instead of account linking or chats. The page reports this user agent:
text
| 1 | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) T3CodeNightly/0.1.1-nightly.20261017.3238 Chrome/152.0.7977.130 Electron/44.4.5 Safari/537.36 |
The reported Chromium version exceeds 100. An embedded-browser identity or compatibility restriction is a hypothesis, not a confirmed root cause. No user-agent override was applied.
Impact
Major degradation or frequent failure. The WhatsApp workflow cannot proceed inside T3.
Version or commit
T3 Code Nightly 0.1.1-nightly.20261017.3238, verified from the installed app's Info.plist.
Environment
macOS 26.2, arm64. T3 integrated browser with the Default profile. Embedded engine reports Chromium 152.0.7977.130 and Electron 44.4.5.
Logs or stack traces
No stack trace for the compatibility page was captured. Separate automation timeouts and inconsistent page readbacks occurred during investigation; a shared cause with WhatsApp's rejection is unproven. Those should remain distinct from this report.
Screenshots, recordings, or supporting files
The exact warning was confirmed in both the native T3 panel and a DOM snapshot. No screenshots of private chats, account credentials, or contact lists are attached.
Workaround
Verified on the same Mac: the existing, signed-in WhatsApp Web application opens the chat list and a conversation successfully. The user's existing Chrome login also works according to the user. No credentials or session data were copied into T3.
Related reports
- #14815 concerns Google Account's unsupported-browser page, not WhatsApp.
- #16901 concerns the agent and visible panel reaching different pages for one logical tab. We also observed inconsistent page readbacks, but that does not establish why WhatsApp rejects the embedded engine.
- #16638 concerned the server browser's headless identity and is closed. The user agent above is the desktop Electron preview, not
HeadlessChrome.
This report does not request weakening browser security or bypassing authentication. It asks for WhatsApp compatibility or a clear unsupported-site handoff.
Synced from GitHub
Retried on the latest nightly (0.1.2-nightly.20261021.3486, macOS 26.7.1 arm64, desktop app with its own local server) and the warning still shows.
Fresh profile (incognito), opened through the agent preview tools
navigator.userAgent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) T3CodeNightly/0.1.2-nightly.20261021.3486 Chrome/152.0.7977.167 Electron/44.9.3 Safari/537.36navigator.userAgentData.brands:[{"brand":"Not?A_Brand","version":"24"},{"brand":"Chromium","version":"152"}]- Result: "WhatsApp works with Google Chrome 100+" (no QR / linking page)
Existing profile that was previously linked: same UA, same brands, same warning. The saved session also appears gone (empty localStorage on web.whatsapp.com).
The issue also appears when the tab is opened with runtime: server. On macOS the "server" browser seems to be the same Electron instance, so it carries the same T3CodeNightly and Electron tokens. This is not the reduced Chrome UA you saw on the Linux server.
The regression appeared after updating on 2026-10-20. On 2026-10-19 the same profile reported ... Chrome/154.0.0.0 Safari/537.36 (no T3CodeNightly or Electron tokens) and WhatsApp Web worked normally.
It would be useful to have a per-tab or per-profile setting to use the reduced Chrome UA and client hints on the desktop (Electron) browser for sites like WhatsApp Web.
Synced from GitHub
Still reproduces on T3 Code (Beta) 0.1.3 (stable channel, Electron 44.9.3 / Chromium 152), macOS 27.2 arm64, desktop app with its own local server, using the built-in browser panel.
https://web.whatsapp.com/shows "WhatsApp works with Google Chrome 100+" every time.- Same result in an incognito profile, and on a second machine.
navigator.userAgent:1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) T3CodeBeta/0.1.3 Chrome/152.0.7977.167 Electron/44.9.3 Safari/537.36
Source check at v0.1.3: apps/desktop/src/preview/BrowserSession.ts still keeps Electron's native UA (the Turnstile trade-off from #7110). On main nothing since then touches the desktop preview UA, so this isn't fixed in the newer nightlies. The Linux server browser avoids it because ServerBrowserContexts.ts applies a reduced Chrome UA plus client hints. +1 for an opt-in per-site or per-profile setting that applies the same override in the desktop browser.
Triaged with Claude Code (Opus 5.5) via t3 triage.
Synced from GitHub
Still reproduces on T3 Code (Beta) 0.1.7 (Electron 44.10.1, Chromium 152.0.7977.169), macOS 27.2.
I narrowed it down: WhatsApp decides on the server, from the User-Agent request header, and the token that triggers the refusal is the app name, not Electron/.
Same request each time (Chrome's navigation headers plus sec-ch-ua: "Chromium";v="152"), only the User-Agent changes:
| User-Agent | Response | "Chrome 100+" page |
|---|---|---|
T3 default (T3CodeBeta/0.1.7 Chrome/152… Electron/44.10.1) | 200, 15.8 KB | yes |
without Electron/44.10.1, keeps T3CodeBeta/0.1.7 | 200, 15.8 KB | yes |
without T3CodeBeta/0.1.7, keeps Electron/44.10.1 | 200, 129 KB (the app) | no |
| plain Chrome 152 | 200, 129 KB (the app) | no |
Inside the built-in browser, fetch('/') on web.whatsapp.com also returns the unsupported page, so this is not a client-side check.
So a host-scoped change like #30018 should be enough here: drop the T3CodeBeta/<version> (or T3CodeNightly/<version>) token from the request header for web.whatsapp.com only. navigator.userAgent and every other site keep the native identity, so the Turnstile trade-off from #7110 stays untouched.