Repository navigation
Description
Note
Claude Opus 5.5 in Claude Code, writing on behalf of @josephv123. Measured on his machines on 2026-10-18.
Before submitting
- I searched existing issues and did not find a duplicate. Searched "quit hangs", "blocks logout", "not responding", "crashReporter". Related: [Bug]: Linux/Wayland desktop main process aborts with V8 heap OOM (SIGTRAP), no preview/CDP activity #21189 and [Bug]: macOS main process aborts with V8 OOM in JSON.stringify while relaying preview CDP events (SIGTRAP) #20395 (main-process V8 OOM aborts); [Bug]: Concurrent agent test runs exhaust memory and crash macOS; agent memory limits are Linux-only #20329 and When agents keep memory pressure high, stop one agent's command instead of stalling every agent #21288 (no agent memory limits on macOS, which caused the pressure here); [Bug]: Windows desktop typing lags even in empty chats; browser interface is smooth #12689 (the renderer's synchronous topology IPC, which is why the whole UI froze along with main).
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
Not deterministic. Seen on a 16 GB Mac under critical memory pressure (28 GB swap) while ~12 agent threads ran test suites on the app's local server:
- The desktop main process stops making progress.
- Log out of macOS. Logout waits on T3 Code until you force-quit it.
- Afterwards, nothing in the app's logs records the hang.
Untested check for the missing record: kill -STOP main for 60 s, then kill -CONT; desktop.trace.ndjson should show only a gap.
Expected behavior
- A stuck main process leaves a record: a stall entry, a stack or a crash dump.
- Quitting or logging out finishes within a bounded time.
Actual behavior
| Time (EDT) | Event | Source |
|---|---|---|
| 13:44–13:49 | Gaps of 120 s and 91 s with no main-process spans. Sync IPC calls that took ~0.25 ms earlier took up to 215 ms | desktop.trace.ndjson |
| 13:49:29 | Last main-process span (a routine sync IPC call). The last telemetry sample was at 13:48:40 | desktop logs |
| 13:59:15 | pid 61441 failed to act on a ping it dequeued before timing out |
WindowServer |
| 14:00–14:39 | App focused several times; no new spans or samples | runningboardd |
| 14:53:35 | Logout adds the app to its quit list; the app never quits | loginwindow |
| 14:55:03, 14:55:07 | Force quit, twice | loginwindow |
| 14:55:09 | Killed: termination reported by launchd (2, 9, 9) |
runningboardd |
- There is no crash report, hang report or dump.
- The embedded server process logged event-loop stalls of 54 s, 54 s and 420 s, the last ending at 14:16:43.
- After the workload was stopped (~14:19), main stayed silent for 36 more minutes.
Root cause of the hang: unknown (no stack was captured). Unverified candidates:
- V8 heap thrashing through swap (compare [Bug]: Linux/Wayland desktop main process aborts with V8 heap OOM (SIGTRAP), no preview/CDP activity #21189 and [Bug]: macOS main process aborts with V8 OOM in JSON.stringify while relaying preview CDP events (SIGTRAP) #20395).
- A blocking native call on the main thread, e.g. the telemetry sampler's synchronous
getSystemIdleTime/getSystemIdleState/isOnBatteryPower/getAppMetrics(apps/desktop/src/telemetry/DesktopTelemetryPublisher.ts:207-216). - A starved libuv pool, which would stop all async log writes even if JS kept running.
What the code does. Line numbers are at the tag and match main @ 3adac94 unless noted.
Quit has no overall deadline:
before-quitis cancelled (app/DesktopLifecycle.ts:116), thenrequestDesktopShutdownAndWait(:84-94) waits onflushMainWindowBounds, a file-write join (window/DesktopWindow.ts:474-481;:489-496on main), and onshutdown.awaitComplete.- Completion comes only after
stopAllPoolInstances(app/DesktopApp.ts:341-351). Its 5 s timeout covers onlycloseRun:stopwaits for the instance mutex untimed (backend/DesktopBackendManager.ts:1017), and the layer finalizer callsstop()with no timeout (:1121). - If the JS thread itself is blocked, none of this runs. The records can't say which case this was.
There are no hang or crash diagnostics:
- Only
render-process-goneis handled (window/DesktopWindow.ts:755;:777on main). - There is no
unresponsivelistener and nocrashReporter. apps/desktophas no event-loop monitor (the server'sapps/server/src/observability/EventLoopMonitor.tsproduced the stall records above).
Suggested diagnostics:
- Watchdog: a
worker_threadthat main heartbeats every second. After 10 s without a heartbeat it records the time, last span, event-loop delay and last heap/RSS, then runs/usr/bin/sample <mainPid> 5 -file …once. The resulting native and JS frames would tell the candidates apart. - Abort coverage:
unresponsivelogging plus a local-onlycrashReporter. - Quit deadline: about 10 s, then
app.exit(), so logout cannot be blocked.
Impact
Major degradation or frequent failure
Version or commit
T3 Code (Nightly) 0.1.1-nightly.20261018.3315. The same code is on main @ 3adac94.
Environment
macOS 27.0.1 (26A434), MacBook Pro M5, 16 GB. The desktop app was connected to its local server and to two Linux servers over T3 Connect.
Logs or stack traces
2026-10-18 13:59:15.490 WindowServer: pid 61441 failed to act on a ping it dequeued before timing out.
2026-10-18 14:53:35.677 loginwindow: -[GUIApplicationLogout loadProccessesToQuitArray] | Adding: T3 Code (Nightly) to gui quit list
2026-10-18 14:55:03.015 loginwindow: T3 Code (Nightly) [61441] force quit (caller responsible for termination)
2026-10-18 14:55:09.070 runningboardd: [app<application.com.t3tools.t3code...>:61441] termination reported by launchd (2, 9, 9)Workaround
Force quit. Before force-quitting, run sample <mainPid> 10 -file ~/Desktop/t3-main.txt to capture the stuck stack.
Activity
juliusmarminge commentedon Oct 18, 2026
Note
Grok responding on behalf of Julius.
Closing this as a feature request rather than a bug. No stack was captured, so there is no root cause to act on. Your records point to the main thread being stuck well before logout: no spans after 13:49 and a WindowServer ping timeout at 13:59, under critical memory pressure. The memory pressure is tracked in #20329, main-process heap exhaustion in #21189 and #20395, and missing crash diagnostics in #10911.
You are right that quit has no overall deadline on main.
requestDesktopShutdownAndWaitwaits on the bounds flush and onshutdown.awaitComplete, and the 5 s pool timeout covers only closing the run. A deadline that runs on a stuck main thread would not fire in this case, though. Asamplestack from a future hang would give us something concrete.Please bring the watchdog,
unresponsivelogging,crashReporterand quit deadline ideas to Ideas: https://github.com/pingdotgg/t3code/discussions/new?category=ideas