[Bug]: 0.0.44 Linux/Wayland renderer disappears, leaving a transparent window while the backend survives

[selmant]

Before submitting

• Searched existing issues, including V8 OOM crash → white screen after extended sessions (Linux) #1686, [Bug]: The app goes blank #1610, and [Bug]: Recurring Blank Screens #2575.
• Included current-build diagnostics and the limits of the available evidence.

Area

apps/desktop

What happened

T3 Code intermittently loses all visible window contents during normal use. In the observed failure on stable 0.0.44, the interior became completely transparent, showing the desktop wallpaper through it, while the compositor's window frame remained visible. There was no visible error message.

During inspection, no --type=renderer process existed anywhere in the app's descendant process tree. The desktop main process, GPU process, network utility process, bundled backend, and a Claude agent process remained alive. Hyprland still reported the main window as mapped and not hidden.

This is a fresh report following the closing comment on #1686, which requested current-build diagnostics after #5148 and #5147. A V8 heap-OOM cause is not established here; this may be a different renderer failure with a similar symptom.

Steps to reproduce

1. Launch the packaged desktop app under Hyprland/native Wayland.
2. Use it normally for an extended session.
3. Intermittently, the main window contents disappear and become transparent.

The observed app instance had been running for approximately 5 hours 18 minutes when renderer-originated IPC stopped. The exact preceding interaction is unknown, and there is no deterministic reproduction yet.

Expected behavior

The UI remains usable, or renderer failure is recovered with a visible diagnostic.

Actual behavior and impact

The window remains mapped but has no visible UI and no renderer process. The backend and agent remain alive, while the desktop UI cannot be used.

Environment

• T3 Code stable 0.0.44; package t3code-bin 0.0.44-1
• Arch Linux / Omarchy, x86_64
• Kernel 7.2.3-arch1-3
• Hyprland 0.56.2-2
• Native Wayland; main process launched with --ozone-platform=wayland
• NVIDIA GeForce RTX 4070; driver 610.57.04
• System RAM reported as 31 GiB; about 14 GiB available during investigation

Sanitized diagnostic excerpts

These are selected fields from actual local diagnostics. Personal paths, hostnames, process/session/trace IDs, window addresses, absolute timestamps, and conversation contents are omitted. Raw profile/provider logs and the screenshot are not attached.

Hyprland client fields:

{"mapped":true,"hidden":false,"class":"com.t3tools.T3Code","xwayland":false,"fullscreen":0}

App scope state and cgroup memory events:

ActiveState=active
SubState=running
Result=success
MemoryPeak=10989887488

memory.events:
low 0
high 0
max 0
oom 0
oom_kill 0
oom_group_kill 0
sock_throttled 0

The roughly 10.24 GiB scope peak includes all descendants, including backend/agent/tool processes. It is not a renderer measurement and does not prove renderer memory exhaustion. Zero cgroup OOM counters do not rule out V8's own heap limit.

Last renderer-originated IPC spans, followed by main-process window-bounds spans, from desktop.trace.ndjson:

{"type":"effect-span","name":"desktop.ipc.window.getLocalEnvironmentBootstraps","durationMs":0.080854,"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"desktop.ipc.window.getLocalEnvironmentBootstraps","durationMs":0.043834,"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"desktop.settings.setMainWindowBounds","durationMs":0.360506,"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"desktop.settings.setMainWindowBounds","durationMs":0.05262,"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"desktop.settings.setMainWindowBounds","durationMs":0.049023,"exit":{"_tag":"Success"}}

Renderer IPC polling ceased. The main-process bounds updates above continued for roughly another 21 seconds; backend trace activity continued afterward.

Other checks:

t3code main stdout -> /dev/null
t3code main stderr -> /dev/null
coredumpctl: no t3code entry
Crashpad: no dump; only client_id file present
PRAGMA quick_check: ok

No system OOM-killer event or kernel GPU fault/reset was found around the incident. At inspection time, GPU memory usage was about 2.5 GiB of 12 GiB.

Diagnosis limits / recovery

The evidence establishes an absent renderer with surviving main/backend processes. It does not identify the renderer exit reason, signal, or a specific triggering action. The launch discarded console errors, and no matching dump or persisted renderer-exit diagnostic was available.

The installed code contains a render-process-gone recovery handler for crashed, oom, and abnormal-exit, with a limit of three attempts per 60 seconds. The window nevertheless remained without a renderer during inspection; the available logs do not show why recovery did not restore it.

Reload/restart was suggested, but its outcome has not been verified. No settings, caches, or conversation data were changed during diagnosis.

---

Prepared by GPT-6 via Codex.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the current-build diagnostics, they're really helpful. This stays open as its own bug: a renderer that disappears mid-session on 0.0.44, not a reopen of the V8 heap OOM in #1686 (closed).

What you captured is enough to place it. Hyprland still had the window mapped, and the main, GPU, network, backend, and agent processes were all alive, but no --type=renderer process remained. The ~10.24 GiB cgroup peak, zero OOM counters, no t3code coredump, and a Crashpad directory with only client_id don't point to renderer heap exhaustion. #1686 had last-resort V8 GC, multi-GB renderer RSS, and a SIGTRAP core, and the fixes for it (#5148 and #5147, both merged) don't cover this case. Nearby reports are different failures: #10911 and #14259 (the main process exits), #10517 and #9239 (blank at startup), and #11308 (React #185 while the renderer is still alive).

Recovery happens in the render-process-gone handler in apps/desktop/src/window/DesktopWindow.ts. It only reloads for crashed, oom, and abnormal-exit, at most 3 times per 60 seconds, and then calls loadURL. killed isn't recovered. On Linux that reason means the renderer died from a signal, which also leaves no core and no Crashpad dump, so it fits your report. A crash loop that uses up the 3-attempt budget would leave the same stuck window. On top of that, loadURL errors are discarded, and a packaged did-fail-load doesn't retry.

The missing trace line is expected too. "main window render process gone" is an Effect warning logged outside any span, desktop.trace.ndjson only keeps logs emitted inside a span, and this process's stdout/stderr go to /dev/null. So the missing line doesn't mean the handler didn't run. The transparent client area fits how the Linux window is set up (titleBarStyle: "hidden" with overlay color #01000000). Once the renderer surface is gone, Ozone/Wayland can composite it as wallpaper while the compositor frame stays up, so the opaque backgroundColor doesn't guarantee a solid dead window.

The fix belongs in the desktop shell. It should record reason, exitCode, and the recovery decision as a trace span, recover from killed as well, and recreate the window or show a fallback whenever a reload is skipped or the budget runs out, instead of leaving a mapped window with no renderer. If you hit it again, it would help to know whether a reload brings the UI back, but we don't need another dump before fixing this gap.

[JorgeMenaDev]

Same symptom on macOS (Apple silicon, 16 GB RAM), desktop 0.0.46-nightly.20261004.2648: the window is frozen/blank, no --type=renderer process is left in the app's tree, while the main process, GPU helper, bundled backend and agent processes keep running and serving threads. The main thread samples idle in the NSApplication event loop.

A likely cause on macOS: jetsam low-swap kills. /Library/Logs/DiagnosticReports/JetsamEvent-*.ips shows two sweeps on this machine (1,079 and 291 processes killed with reason low-swap), with swap around 13–21 GB used. The main renderer was still alive in the second report, and was gone a few hours later; I could not capture its exit reason.

One gap in recovery: the render-process-gone handler in apps/desktop reloads only for crashed, oom and abnormal-exit. A renderer killed by the OS (SIGKILL) arrives as killed, which Electron documents as distinct from oom, so the window is never recovered. Two suggestions:

1. Treat killed as recoverable too (within the existing retry cap).
2. Log the render-process-gone reason/exit code to the desktop trace so the cause is visible after the fact. Here, the warning could not be found in desktop.trace.ndjson.

[ammarfrahm]

Same problem on macOS. A manual SIGKILL causes it.

Environment: macOS (Darwin 25.6.0), Apple silicon, 16 GB, T3 Code 0.0.46-nightly.20261005.2667

What I saw: At 05:55:52, the main window became black. No --type=renderer process stayed. The main process, GPU helper, backend and agents continued to operate. Chrome, Bitwarden and Pritunl helpers also started again at the same second. No JetsamEvent or crash report exists for that time. desktop.trace.ndjson has no entry. Cmd+R did not repair the window. A full restart did.

Procedure:

ELECTRON_ENABLE_LOGGING=1 "/Applications/T3 Code (Nightly).app/Contents/MacOS/T3 Code (Nightly)" > t3.log 2>&1
kill -9 $(pgrep -f 'Nightly\).*--type=renderer')    # window stays black
kill -SEGV $(pgrep -f 'Nightly\).*--type=renderer') # window reloads in approx. 2 s

Log:

WARN main window render process gone  reason: killed   exitCode: 9   recovering: false
WARN main window render process gone  reason: crashed  exitCode: 11  recovering: true

After the SIGKILL, the main process also writes Render frame was disposed before WebFrameMain could be accessed 2 times in 3 s.

Cause: DesktopWindow.ts reloads only for crashed, oom and abnormal-exit. SIGKILL gives killed. macOS jetsam also uses SIGKILL. The warning goes only to stdout, and a Dock launch sends stdout to /dev/null.

Proposed fix:

1. Add killed to the reload reasons. The 3-in-60 s limit prevents a loop.
2. Write reason, exitCode and recovering to the desktop trace.
3. If no reload occurs, show a fallback screen.