Skip to content

Built-in browser does not render or navigate on v0.0.46 nightlies; desktop browser tools report "No desktop browser is connected to this session" #17009

Open
Open
Built-in browser does not render or navigate on v0.0.46 nightlies; desktop browser tools report "No desktop browser is connected to this session"#17009
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@p7gg
p7gg
opened on Oct 8, 2026

What happened

I use the nightly channel. Since the Orchestrator V2 nightlies (the first was 20261003.2610), the built-in browser in the desktop app stopped working. Opening the Browser surface shows the tab and the local-servers list, but typing a URL and pressing Enter does nothing: the field clears back to "Search or enter URL" and no page ever loads, with no error anywhere in the UI. Agents in the thread cannot use the browser either — the desktop browser tools fail with [browser.disconnected] No desktop browser is connected to this session even though the desktop app is open on the thread. Restarting the app and rebooting the machine did not help. A screen recording shows the pane accepting google.com and then doing nothing.

Diagnosis

Agent-assisted investigation on the machine:

  • Reproduced the agent-side failure live: browser.tabs.list and browser.tabs.open both fail with [browser.disconnected] No desktop browser is connected to this session. Open this session in the desktop app and wait for it to connect. while the desktop app is open on the thread. It persists across an app restart and a full reboot.
  • Differential: server-hosted preview tabs still work. preview_open + preview_navigate to https://example.com succeeds and the tab reports the URL and title correctly (the tab was closed afterwards). So the server browser host is fine; the desktop browser host is the one that does not attach.
  • No server-child*.log* files exist. Per the triage docs those are written only when a desktop backend crashes or fails to start, so the desktop backend is not crashing.
  • server.trace.ndjson shows orchestration-v2.* startup spans; no browser-related error spans were found.
  • The reporter first hit this after updating to the V2 nightlies; it worked before.

Steps to reproduce

  1. Desktop app (Windows) connected to a T3 server on WSL2.
  2. Open a thread, open the Browser surface ("Open a surface" → Browser).
  3. Type google.com and press Enter. The field clears back to the placeholder; the pane stays on the "Local servers" list; nothing loads and no error is shown. Clicking a listed local server does nothing either.
  4. In the same thread, have an agent call browser.tabs.list. It fails with [browser.disconnected] No desktop browser is connected to this session.
  5. Quit and reopen the app, reboot the machine: unchanged.

Version

0.0.46-nightly.20261007.2787

Environment

Windows 11 host + WSL2 (kernel 6.18.33.2-microsoft-standard-WSL2); T3 server on the WSL side (linux x64); the desktop app connects to it. Environment label P7-DESKTOP.

Evidence

agent -> browser.tabs.list
[browser.disconnected] No desktop browser is connected to this session. Open this session
in the desktop app and wait for it to connect.

agent -> preview_open + preview_navigate https://example.com   (server-hosted tab)
available: true, url: https://example.com/, title: "Example Domain"

$ ls ~/.t3/userdata/logs/server-child*
none
$ grep -ic browser ~/.t3/userdata/logs/server.trace.ndjson
0

Screen recording of the dead pane: will be attached in a comment.

Related issues

Fix applied or workaround

None yet — investigation only; nothing was changed on the machine.

Filed by

opencode (deepseek-v4.1-flash) in a T3 Code agent session — agent-assisted triage; structure follows the via-triage template.

Activity

  1. juliusmarminge commented on Oct 8, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 8, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Thanks for the detailed report and the server-tab differential. I traced this in code on main (ff3a04a) but haven't reproduced it in a running app. I found a specific path that matches every symptom, if your desktop app runs in WSL-only mode, meaning the WSL backend is the app's primary backend rather than a second backend next to the Windows one. Can you confirm which setup you have?

    Likely mechanism (WSL-only primary)

    1. The WSL primary never gets the desktop browser channel. The Windows primary is spawned with browser fds 6/7 (DesktopBackendConfiguration.ts L574-L575). In WSL-only mode, resolvePrimary uses buildWslPrimaryConfig instead. That reuses the primary's port and identity ("primary-aware code paths … keep working"), but its bootstrap has no browser fds and is delivered over stdin (L773), because "wsl.exe drops additional file descriptors" (DesktopBackendManager.ts L504-L507). On the server, that makes DesktopBrowserChannel available: false. desktopRenders then returns false, and every tab runs on the server's own headless page. That's why preview_open/preview_navigate work for agents.
    2. The client still renders those tabs natively. Every server advertises serverBrowser: true, so new tabs get runtime: "server". rendersServerTabNatively only checks Electron, runtime === "server" and environment == primary. It can't tell that this server has no desktop channel. So ElectronBrowserHost mounts a local <webview> marked serverDriven, and PreviewView treats the tab as native instead of streaming it.
    3. URL entry goes to that local webview, and the server never hears about it. Submitting calls previewBridge.navigate on the desktop webview. For serverDriven tabs the bridge skips reporting status (usePreviewBridge.ts L84), because the server normally sees navigation over the channel. Here there's no channel, so the server's snapshot stays Idle. Then:
      • The address bar blurs on submit (PreviewChromeRow.tsx L106-L112) and shows the snapshot URL (L183, PreviewView.tsx L194). That URL is "", so you see the placeholder again.
      • Idle keeps the empty state (Local servers) on screen, and the webview slot isn't rendered.
      • Local-server clicks go through the same navigate path. No error appears anywhere, so it fails silently.

    Agents' preview_* tools and your panel end up on two different pages. That's the same class of split as #16901, except there it happens after a 10s attach timeout, and here it happens on every tab.

    Not from T3 Code: the [browser.disconnected] No desktop browser is connected to this session string and the browser.tabs.list/browser.tabs.open tool names don't appear anywhere on main. T3 Code's agent browser tools are preview_*. That error most likely comes from the agent harness's own browser tooling, so it isn't evidence about the T3 desktop host.

    Timing: this path came in with #15328 (merged Oct 6). The first nightly that includes it is 0.0.46-nightly.20261006.2735. The V2 nightlies you mention (20261003.2610 through 20261005.2702) don't have it. If the pane really was dead on those builds, something else is also involved. Please say whether it worked on 20261005.2702.

    Next steps / fix options (unverified)

    • Make "native vs. stream" depend on whether the server actually has the desktop channel. For example, the server could advertise a capability only when DesktopBrowserChannel.available, and rendersServerTabNatively could require it. Without it, a WSL-only primary would stream its headless tabs like any other environment.
    • Alternatively, have the desktop mark a stdin-bootstrapped (WSL) primary as not natively rendered.
    • Longer term, carry the browser channel over a transport that survives wsl.exe, such as a loopback socket, so WSL tabs render natively too.
    • Possible workaround (untested): turn off WSL-only mode and add WSL as a second backend next to the Windows one. Its tabs should then stream instead of using the local webview.

    To confirm

    • Is the desktop app in WSL-only mode? Does the WSL environment show as the primary/"This machine" environment in Settings → Connections?
    • Did the Browser panel work on nightly 20261005.2702 and stop on 20261006.2735 or later?

    Related

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 8, 2026

  3. p7gg commented on Oct 8, 2026

    @p7gg
    p7gg
    on Oct 8, 2026
    Author

    Confirming from the machine — thanks for the trace, it matches what we see:

    • WSL-only mode: yes. The app's only backend runs in WSL (wsl.exe -d archlinux --exec … t3 --bootstrap-fd 0); there is no Windows-side backend process (only the Electron UI processes), and the app ships wsl-runtime.tar.gz in its resources.
    • Timing: not sure, unfortunately. My first clear repro is on 20261007.2787, and I can't confirm whether the Browser surface worked on 20261005.2702 — my impression was that it broke with the V2 nightlies, but I can't pin the build.
    • The pane behavior matches your steps: on submit the address bar shows the empty snapshot URL (placeholder again) and the "Local servers" empty state stays; no error anywhere. The app created local preview webview partitions on the Windows side today (t3code-preview-*), consistent with your step 2.
    • Noted on [browser.disconnected] / browser.tabs.* — that's the agent harness, not T3 Code; I'll disregard it as evidence about the desktop host.

    Happy to test a build with the capability-gated fix, or report back if the workaround (WSL as a second backend next to Windows) changes anything.

  4. p7gg commented on Oct 8, 2026

    @p7gg
    p7gg
    on Oct 8, 2026
    Author

    video of the issue:

    20261007-2333-47.5836394.mp4

  5. theDanielJLewis commented on Oct 10, 2026

    @theDanielJLewis
    theDanielJLewis
    on Oct 10, 2026

    I'm having I think a similar issue with 0.0.46-nightly.20261010.2908 (3e94afa) on macOS 26. But it seems like the browser URL never updates. But it will navigate to the URL I enter, even though it reverts the displayed URL.

    Clipboard-20261010-055421-656.mp4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions