[GH-ISSUE #255] Crash: uncaught "Cannot resize a pty that has already exited" kills the entire app — reproducible from Settings/Update with Open Terminal unavailable (Windows) #165

Open
opened 2026-10-18 14:06:38 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @Iory1998 on GitHub (Aug 7, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/255

Open WebUI Desktop crashes with an Electron error dialog:

A JavaScript error occurred in the main process
Uncaught Exception:
Error: Cannot resize a pty that has already exited
at WindowsPtyAgent.resize (C:\Users\ioryy\AppData\Local\Programs\open-webui\resources\app.asar\node_modules...:23)
at WindowsTerminal. (...:26)
at WindowsTerminal._deferNoArgs (...:24)
at WindowsTerminal.resize (...:14)
at MessagePortMain. (...\out\main\index.js:21)
at MessagePortMain.emit (node:events:519:28)
at MessagePortMain._internalPort.emit (node:electron/js2c/browser_init:2:117074)

Environment

OS: Windows 11 Pro
Open WebUI Desktop version: 0.0.18 (when first encountered); still reproducible after updating to v0.0.20 (latest release at time of writing)
Model access: remote API connection only (llama.cpp server stopped)
Open Terminal server: not running / unavailable during the reliable reproduction below
Steps to reproduce (reliable — screen recorded)

The recording shows the following sequence; the crash occurs even though Open Terminal is not available (Terminal unavailable: Terminal server [http://127.0.0.1:38234/] not found):

Launch Open WebUI Desktop on Windows 11.
Open the bottom console tab to view the embedded server logs (uvicorn.protocols.http.h11_impl).
Collapse the console, open the sidebar, and open Settings (gear icon, bottom left).
Switch to the "Open WebUI" tab (server status shows Running).
Click the Update button (Updating...).
Return to the main chat workspace: a "Connection lost, Reconnecting..." notice appears, then the canvas enters a "Starting Open WebUI..." loading state.
As the interface reloads, the main process throws the fatal error dialog above (≈00:17 in the recording).
Additional observations

The crash is not caused by the user-facing Terminal feature. It reproduces with the Open Terminal server unavailable, which indicates the failing PTY belongs to the desktop app's own embedded Open WebUI server process (spawned so its output can be shown in the console tab), not to a user terminal session.
Two different outcomes depending on trigger:
Update path (reliable): the error dialog appears, but the embedded server still launches afterwards and the app continues.
During normal use: while a chat response is being generated (models via API, Open Terminal active and being used by the LLM to modify files on disk), the embedded server disconnects permanently and the app becomes unusable. The only remedy is to completely close and relaunch the app. This happens frequently (not every time), especially when switching conversations or opening the app settings mid-generation.
I have not isolated whether an explicit window resize is required; the crash also occurs without one (e.g., immediately after the console tab opens during server restart), suggesting any resize/layout event racing with process teardown can trigger it.
Expected behavior

The app must not crash when a resize is delivered to a PTY whose process has already exited. The resize should be ignored or handled gracefully instead of throwing an uncaught exception in the main process.

Additional context

https://github.com/user-attachments/assets/7cc3c96c-c467-471c-826d-00babcf5429c

Screen recording of the reliable reproduction is available on request.
This matches the known Windows node-pty behavior where resize throws Cannot resize a pty that has already exited; the same crash pattern is reported in other node-pty-based applications on Windows (e.g., microsoft/node-pty#827).

Originally created by @Iory1998 on GitHub (Aug 7, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/255 Open WebUI Desktop crashes with an Electron error dialog: A JavaScript error occurred in the main process Uncaught Exception: Error: Cannot resize a pty that has already exited at WindowsPtyAgent.resize (C:\Users\ioryy\AppData\Local\Programs\open-webui\resources\app.asar\node_modules\...:23) at WindowsTerminal.<anonymous> (...:26) at WindowsTerminal._deferNoArgs (...:24) at WindowsTerminal.resize (...:14) at MessagePortMain.<anonymous> (...\out\main\index.js:21) at MessagePortMain.emit (node:events:519:28) at MessagePortMain._internalPort.emit (node:electron/js2c/browser_init:2:117074) Environment OS: Windows 11 Pro Open WebUI Desktop version: 0.0.18 (when first encountered); still reproducible after updating to v0.0.20 (latest release at time of writing) Model access: remote API connection only (llama.cpp server stopped) Open Terminal server: not running / unavailable during the reliable reproduction below Steps to reproduce (reliable — screen recorded) The recording shows the following sequence; the crash occurs even though Open Terminal is not available (Terminal unavailable: Terminal server [http://127.0.0.1:38234/] not found): Launch Open WebUI Desktop on Windows 11. Open the bottom console tab to view the embedded server logs (uvicorn.protocols.http.h11_impl). Collapse the console, open the sidebar, and open Settings (gear icon, bottom left). Switch to the "Open WebUI" tab (server status shows Running). Click the Update button (Updating...). Return to the main chat workspace: a "Connection lost, Reconnecting..." notice appears, then the canvas enters a "Starting Open WebUI..." loading state. As the interface reloads, the main process throws the fatal error dialog above (≈00:17 in the recording). Additional observations The crash is not caused by the user-facing Terminal feature. It reproduces with the Open Terminal server unavailable, which indicates the failing PTY belongs to the desktop app's own embedded Open WebUI server process (spawned so its output can be shown in the console tab), not to a user terminal session. Two different outcomes depending on trigger: Update path (reliable): the error dialog appears, but the embedded server still launches afterwards and the app continues. During normal use: while a chat response is being generated (models via API, Open Terminal active and being used by the LLM to modify files on disk), the embedded server disconnects permanently and the app becomes unusable. The only remedy is to completely close and relaunch the app. This happens frequently (not every time), especially when switching conversations or opening the app settings mid-generation. I have not isolated whether an explicit window resize is required; the crash also occurs without one (e.g., immediately after the console tab opens during server restart), suggesting any resize/layout event racing with process teardown can trigger it. Expected behavior The app must not crash when a resize is delivered to a PTY whose process has already exited. The resize should be ignored or handled gracefully instead of throwing an uncaught exception in the main process. Additional context https://github.com/user-attachments/assets/7cc3c96c-c467-471c-826d-00babcf5429c Screen recording of the reliable reproduction is available on request. This matches the known Windows node-pty behavior where resize throws Cannot resize a pty that has already exited; the same crash pattern is reported in other node-pty-based applications on Windows (e.g., microsoft/node-pty#827).
Author
Owner

@Iory1998 commented on GitHub (Aug 8, 2026):

UPDATE (and Workaround)

I instructed Deepseek-v4-flash to read my file locally, and it found a workaround that seems to fix the issue.

Root cause found and verified — local workaround applied successfully (still reproducible on v0.0.20, fixed locally)

Root cause

This crash is not specific to the user-facing Open Terminal feature. The failing PTY belongs to the desktop app's own embedded Open WebUI server process — the one spawned so its output can be shown in the console tab. That's why it reproduces even when the Open Terminal server is unavailable (as in the attached recording).

The error comes from node-pty 1.1.0 (bundled with the app). Its WindowsPtyAgent.resize():

WindowsPtyAgent.prototype.resize = function (cols, rows) {
if (this._useConpty) {
if (this._exitCode !== undefined) {
throw new Error('Cannot resize a pty that has already exited');
}
this._ptyNative.resize(this._pty, cols, rows, this._useConptyDll);
return;
}
this._ptyNative.resize(this._pid, cols, rows);
};

When a resize/layout event arrives after the server process has exited (e.g. opening the console tab while the server restarts after clicking Update), the throw becomes an uncaught exception in the Electron main process, which kills the whole app including the embedded server. The app's own call site in out/main/index.js (the pty:port MessagePort handler) calls ptyProcess.resize(msg.cols, msg.rows) with no guard and no try/catch, so nothing catches it.

This is a known Windows node-pty behavior — the identical crash is reported across other node-pty consumers (microsoft/node-pty#827, Google Gemini CLI, etc.), where the consensus expected behavior is: "resize after PTY exit should fail gracefully or be ignored, not crash the entire process."

Local workaround (verified on v0.0.20)

Changed the throw to a no-op return; in the unpacked node-pty:
resources\app.asar.unpacked\node_modules\node-pty\lib\windowsPtyAgent.js

         if (this._exitCode !== undefined) {
  •            throw new Error('Cannot resize a pty that has already exited');
    
  •            return;
           }
    

After process exit, resize() becomes a harmless no-op. Live terminals are unaffected — the guard only triggers once the process has already exited, so nothing is lost by skipping the native resize call.

Verification

The previously 100%-reproducible sequence (Settings → Open WebUI → Update → open console tab during server restart) now passes clean — no error dialog, server starts normally.
Patch confirmed on disk (byte-level check), original file backed up.
Applied via a small self-verifying patcher script that was selftested against the real installed file before touching anything; it also refuses to patch if an app update ever changes the file structure.
Important caveat

The app's auto-updater replaces the whole resources folder, so every Open WebUI Desktop update reverts this patch and it must be re-applied. Local workaround only — other users won't have it.
Suggestion to maintainers

The durable fix is app-side: in out/main/index.js, guard the pty:port resize handler (if (ptyProcess.exitCode !== undefined) return; or wrap the call in try/catch), and/or fix it upstream in node-pty — changing that throw to return fixes the crash for every Electron app on Windows at once (see microsoft/node-pty#827).

<!-- gh-comment-id:5223649854 --> @Iory1998 commented on GitHub (Aug 8, 2026): **UPDATE (and Workaround)** I instructed Deepseek-v4-flash to read my file locally, and it found a workaround that seems to fix the issue. Root cause found and verified — local workaround applied successfully (still reproducible on v0.0.20, fixed locally) Root cause This crash is not specific to the user-facing Open Terminal feature. The failing PTY belongs to the desktop app's own embedded Open WebUI server process — the one spawned so its output can be shown in the console tab. That's why it reproduces even when the Open Terminal server is unavailable (as in the attached recording). The error comes from node-pty 1.1.0 (bundled with the app). Its WindowsPtyAgent.resize(): WindowsPtyAgent.prototype.resize = function (cols, rows) { if (this._useConpty) { if (this._exitCode !== undefined) { throw new Error('Cannot resize a pty that has already exited'); } this._ptyNative.resize(this._pty, cols, rows, this._useConptyDll); return; } this._ptyNative.resize(this._pid, cols, rows); }; When a resize/layout event arrives after the server process has exited (e.g. opening the console tab while the server restarts after clicking Update), the throw becomes an uncaught exception in the Electron main process, which kills the whole app including the embedded server. The app's own call site in out/main/index.js (the pty:port MessagePort handler) calls ptyProcess.resize(msg.cols, msg.rows) with no guard and no try/catch, so nothing catches it. This is a known Windows node-pty behavior — the identical crash is reported across other node-pty consumers (microsoft/node-pty#827, Google Gemini CLI, etc.), where the consensus expected behavior is: "resize after PTY exit should fail gracefully or be ignored, not crash the entire process." Local workaround (verified on v0.0.20) Changed the throw to a no-op return; in the unpacked node-pty: resources\app.asar.unpacked\node_modules\node-pty\lib\windowsPtyAgent.js if (this._exitCode !== undefined) { - throw new Error('Cannot resize a pty that has already exited'); + return; } After process exit, resize() becomes a harmless no-op. Live terminals are unaffected — the guard only triggers once the process has already exited, so nothing is lost by skipping the native resize call. Verification The previously 100%-reproducible sequence (Settings → Open WebUI → Update → open console tab during server restart) now passes clean — no error dialog, server starts normally. Patch confirmed on disk (byte-level check), original file backed up. Applied via a small self-verifying patcher script that was selftested against the real installed file before touching anything; it also refuses to patch if an app update ever changes the file structure. Important caveat The app's auto-updater replaces the whole resources folder, so every Open WebUI Desktop update reverts this patch and it must be re-applied. Local workaround only — other users won't have it. Suggestion to maintainers The durable fix is app-side: in out/main/index.js, guard the pty:port resize handler (if (ptyProcess.exitCode !== undefined) return; or wrap the call in try/catch), and/or fix it upstream in node-pty — changing that throw to return fixes the crash for every Electron app on Windows at once (see microsoft/node-pty#827).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
open-webui/desktop#165
No description provided.