Repository navigation
[Bug]: Windows/WSL browser panel shows signed-in desktop session while agent sees separate unsigned-in Linux page #27035
Description
Before submitting
- Searched existing issues. This appears related to closed [Bug]: Agent and browser panel show two different browser pages for the same browser tab #16901; reporting a current Windows/WSL reproduction.
- Included reproduction steps and redacted diagnostic evidence.
Area
apps/desktop / apps/server collaborative browser
Steps to reproduce
- Run T3 Code (Beta) desktop on Windows with the Ubuntu WSL2 backend, using Codex.
- Keep the thread open and ask the agent to open a new browser tab:
preview_open({url:"https://example.com",open:true,reuseExistingTab:false}). - The user sees the page in the T3 browser panel. Ask the agent for a screenshot of that tab. In this reproduction the user sees dark mode, while the agent screenshot shows a light page.
- Ask the agent to open
https://www.linkedin.com/jobs/in that tab. - The user sees their already signed-in LinkedIn account in the T3 panel. The agent's
preview_snapshotof the returned tab shows the unsigned-in "Join LinkedIn" auth wall. - Repeat with a fresh tab and after restarting T3. The session mismatch persists. Indeed also showed a discrepancy: the user reported being signed in, while the agent saw a Cloudflare verification page.
Expected behavior
The browser panel and agent tools operate on the same page and profile. A sign-in visible to the user should also be visible to the agent. If two browser runtimes are intentionally separate, the UI and tools should clearly identify this rather than presenting the tab as shared.
Actual behavior
The user sees an authenticated desktop page; the agent reads and screenshots an unauthenticated Linux page. Successful open/show requests continue to report visible:false even while the user can see the tab.
Impact
Major degradation: authenticated browser-assisted work is blocked. Asking the user to sign in again cannot solve it because their displayed page is already signed in.
Version and environment
- T3 server reports version
0.1.5. - Windows T3 Code (Beta) desktop, Ubuntu WSL2 backend, Linux arm64.
- Codex provider.
- Agent-controlled browser executable: T3-managed
chrome-headless-shell/linux-arm64/156.0.8078.70. - Profile path (redacted):
~/.t3/userdata/server-browser/profiles/default. - Page navigator reports
platform:"Linux x86_64", languageen-US.
Diagnostic evidence
Redacted successful open response:
{
"available": true,
"visible": false,
"url": "https://www.linkedin.com/jobs/",
"control": {"owner": "agent", "ownedByCaller": true},
"viewport": {"width": 1280, "height": 800},
"tabs": [{"profileId": "default", "visible": false}]
}t3_preview_list reports runtime:"server", with reveal requested, but no headless field in the listed session.
Agent snapshot:
- title:
Sign Up | LinkedIn - location:
https://www.linkedin.com/authwall(query omitted) - text:
Join LinkedIn,Email,Password (6+ characters),Already on Linkedin? Sign in
At the same time the user explicitly confirmed their own account was visible in the panel. An earlier user-supplied screenshot also confirmed the authenticated desktop view.
Possible investigation lead (not a confirmed root cause)
Inspection of the installed bundles found desktop-render selection equivalent to:
runtime === "server" && !headless && environmentId === localEnvironmentIdand server-side headless marking conditional on:
if (!desktop && desktopChannel.available) manager.markHeadless(...)Please check the WSL case where the desktop channel is unavailable and the session does not get marked headless: could the panel render a native desktop webview while tools use the server's headless page?
Workaround / investigation caveat
No working workaround confirmed. A local experimental client patch was attempted during diagnosis, caused a UI loading failure, and was fully reverted. Original application files were restored and verified against their backups. The browser mismatch was observed before that experiment and reproduced again after restoration and restart. The experimental patch is not presented as a fix.
Related: #16901 (same two-pages-for-one-tab symptom), #17015 (visible:false after open/show).
Activity
sod-efi commentedon Nov 3, 2026
Your report has the problem in one picture. You see your signed-in LinkedIn in the T3 panel. The agent sees a page asking you to join LinkedIn. Two profiles, and the login lives in the wrong one.
I built a tool to close that gap. Nephew keeps the browser profile you logged into yourself, as one file you own, and loads it into whatever sandbox your agent runs in. The agent starts from your session, not a Linux page of its own. A Cloudflare check may still test the browser itself, and no profile answers that for certain.
I will set it up with you live, free. You pay nothing unless your run finishes logged in. Only then does the $19 a month plan start.
nephew.ai
— Efi
Emmaqm commentedon Nov 4, 2026
Still reproduces on 0.1.7, on x64 with the Claude provider, so it's not arm64- or Codex-specific.
Environment
wslBackendEnabled: true,wslOnly: true), Linux x86_640.1.7, running from the staged WSL runtimechrome-headless-shell/linux64/156.0.8078.80Repro
preview_open({url:"https://example.com", reuseExistingTab:false})→visible:falsepreview_evaluateinjects a fixed red banner with a counter that increments every second and changesdocument.titlepreview_statusstill reportsvisible:falseafterwards.The page the agent drives and the page in the panel are two different browsers. The tab lives in the WSL headless shell; the panel renders its own Electron
<webview>that only mirrors the URL.What I saw in the client
/api/preview-stream/wsfor these tabs, so the server tab never gets a viewer (tab.viewers.size === 0→visible:false).runtime === "server"session whose environment is the local primary environment, the client takes the local-webview path instead of the stream path. In the 0.1.7 bundle (browserDefaults-*.js):This looks like the same split #16901 addressed with the desktop-attach timeout, except that under WSL the desktop webview isn't the agent's page, so the user ends up silently watching a different browser.
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Not run in a real app: the reporter's setup needs Windows T3 Code desktop with a WSL2 backend, which no worker has. Instead, on origin/main 6ba3de7 I added a test to apps/server/src/preview/ServerBrowser.test.ts. It makes the mocked DesktopBrowserChannel unavailable, the way a WSL backend starts, and opens a tab through the preview automation broker. On main the tab's PreviewManager session has headless === undefined (expected true). With the
desktopChannel.availablecondition removed from ServerBrowser.setUpTab, all 70 tests in the file pass (I reverted that change). The test is pushed as factory/repro-27035 (c57d7f3). Code check: the desktop passes desktopBrowserFd/desktopBrowserControlFd only in its native bootstrap, not in the WSL start config (confirmed in the #28488 analysis), so the WSL server gets the unavailable channel.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.