Skip to content

[Bug]: Windows: resident server-browser host's chrome-headless-shell GPU process (SwiftShader) busy-spins ~5 cores for hours while idle #18165

Open
Open
[Bug]: Windows: resident server-browser host's chrome-headless-shell GPU process (SwiftShader) busy-spins ~5 cores for hours while idle#18165
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@kinpoe-ray
kinpoe-ray
opened on Oct 11, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Not fully deterministic yet; this is the observed state on my machine.

  1. Use the app with agent HTML previews (html_preview / html_render through the shared server browser). The desktop app spawns a resident chrome-headless-shell.exe host with --user-data-dir=...\.t3\userdata\server-browser\profiles\default.
  2. Stop using previews and leave the app running (no active turns, preview panel not in use).
  3. Hours later the machine is hot, the fan is loud, and Task Manager shows chrome-headless-shell eating most of the CPU.

Expected behavior

The resident server-browser host should not burn CPU when nothing is being previewed or captured. Ideally it would throttle/stop compositing when idle, or exit after an idle timeout and respawn on demand.

Actual behavior

The --type=gpu-process child of the resident host busy-spins continuously while everything else is idle:

  • Host chrome-headless-shell.exe (PID 13844) was spawned by T3 Code (Nightly).exe at 13:13:29 and stayed resident showing about:blank.
  • At ~16:14 its GPU process (PID 65860) had accumulated 913.9 CPU-minutes (15.2 CPU-hours) over ~3 h wall time — a steady ~5 of 16 logical cores, i.e. ~72% total machine CPU.
  • The renderer processes had ~0.2–0.3 CPU-seconds each, so the work was all in the GPU process.
  • Launch flags: host has --disable-gpu --force-device-scale-factor=2; the GPU process runs --use-angle=swiftshader-webgl --enable-unsafe-swiftshader, i.e. pure CPU rasterization with no real GPU.
  • Killing the whole tree dropped machine CPU from 73% to 3.6% within seconds.

This looks related to the family of "hidden/unused preview surfaces keep consuming resources" bugs — #17180 (Linux stale preview tab holding a "Capturing" wake lock), #14730 (macOS hidden previews still rendering), #15579 (hidden webviews stay alive until restart) — but this one is the Windows server-browser host's SwiftShader GPU process spinning while idle, not a stale visible tab.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261011.2955

Environment

Windows 11 Pro 10.0.22631, Intel i7-10700F (8 cores / 16 threads), desktop app (nightly channel), bundled chrome-headless-shell 154.0.8037.92

Logs or stack traces

chrome-headless-shell  72.1 %  (top process; total machine CPU 73.0 %, 16 cores)
t3 code (nightly)       0.5 %
everything else        <= 0.4 %

Process tree (Win32_Process + Get-Process):
PID 13844  chrome-headless-shell.exe            started 13:13:29  CPU 0.1 min
  parent: 39972: T3 Code (Nightly).exe
  cmdline: ...\t3\tools\chrome-headless-shell\win64\154.0.8037.92\chrome-headless-shell.exe
           --disable-gpu --force-device-scale-factor=2 --headless --hide-scrollbars
           --user-data-dir=...\.t3\userdata\server-browser\profiles\default
           --remote-debugging-pipe about:blank

PID 65860  chrome-headless-shell.exe --type=gpu-process   started 13:13:29
  CPU 913.9 min (15.2 CPU-hours)  Mem 572 MB     <-- the burner
  flags: --use-angle=swiftshader-webgl --enable-unsafe-swiftshader

PID 73276  --type=utility (network service)     CPU 0
PID 45000  --type=renderer  created 16:04:16    CPU 0.3 s
PID 30640  --type=renderer  created 16:14:41    CPU 0.2 s

After Stop-Process -Id 13844 (whole tree):

chrome-headless-shell: all gone
Total CPU now: 3.6 %

Workaround

Kill chrome-headless-shell.exe (or restart the app) whenever the fan spins up. It respawns on the next preview with no visible data loss.

Activity

  1. juliusmarminge commented on Oct 11, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 11, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    This is a real bug: the resident server-browser host is launched with --disable-gpu (so Chromium keeps a SwiftShader GPU process), and nothing on main tears that host down when previews go idle.

    What main does

    • Launch args are --disable-gpu and --force-device-scale-factor=2 (ServerBrowserContexts.launchOptions). The file comment says that deliberately keeps SwiftShader WebGL while using software compositing — which matches your --use-angle=swiftshader-webgl --enable-unsafe-swiftshader GPU child.
    • The default profile uses chromium.launchPersistentContext(...), so the host stays up under .t3/userdata/server-browser/profiles/default after the first preview.
    • Idle cleanup only closes unused agent tabs after 30 minutes (AGENT_TAB_IDLE_MS / closeIdleAgentTabs). Closing a tab drops the page; for the default profile it does not close the persistent context. The chrome-headless-shell tree is disposed only when the server browser itself shuts down.
    • There is no host-level idle exit or respawn-on-demand.

    So your process tree (resident host on about:blank, GPU child burning CPU, renderers idle) matches the architecture. Chromium is also known to keep a GPU process under --disable-gpu and route WebGL through SwiftShader; the multi-hour busy-spin on a blank page looks like that path misbehaving, but T3 is what leaves the host running for hours with nothing to do.

    Not a duplicate of / not covered by

    • #15579 / #17180 / #14730 — desktop Electron preview guests / wake locks, not the shared chrome-headless-shell host.
    • #16921 — host eviction on automation timeouts.
    • #17090 — WSL stream lag while using a preview.
    • Open PR #18147 — keeps desktop-rendered tabs out of the agent idle sweep; it does not idle-exit or retarget the headless host.

    Workaround

    Kill chrome-headless-shell (or restart the app) when the fan spins up; it comes back on the next preview. Until there is a host idle timeout (or a less hungry GPU setup), that remains the practical fix.

    I did not reproduce the spin at runtime; the lifecycle and flags above are from current main.

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

  3. diyaavirmani commented on Oct 11, 2026

    @diyaavirmani
    diyaavirmani
    on Oct 11, 2026

    Hi @juliusmarminge , I’d like to investigate this issue. I’ve read the contribution guidelines and your explanation of the persistent browser host’s lifecycle.

    I propose investigating host-level idle cleanup and relaunch on demand, ensuring active previews and browser operations remain protected. I’d add focused lifecycle tests and seek Windows validation of the reported CPU usage. I also noted that #18147 addresses desktop-rendered tab cleanup rather than this headless-host issue.

    If this is available, could you please assign it to me and confirm whether that approach fits the intended scope? Thanks!

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