[GH-ISSUE #251] bug: interactive terminal session freezes long-running processes when the browser client disconnects #163

New issue

Open

opened 2026-10-18 14:03:30 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-18 14:03:30 +00:00

Owner

Originally created by @1-kabir on GitHub (Sep 5, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/251

bug: interactive terminal session freezes long-running processes when the browser client disconnects

Bug description

Interactive (PTY) terminal sessions only drain their PTY output while a
browser WebSocket client is attached. If the client disconnects — closed tab,
suspended laptop, browser backgrounded/killed — nothing reads the PTY master
fd anymore, and the kernel PTY buffer (~64 KB) eventually fills up. Any
long-running process attached to the terminal (e.g. a CLI agent, a build, a
tail) then blocks on write() until a client reconnects. Output produced
while detached is also lost beyond the kernel buffer.

This makes the terminal unusable as a place to run anything long-lived that
produces output.

To Reproduce

Open an interactive terminal session and start a process that emits more than ~64 KB of output over time (e.g. yes | head -c 100M or a long build).
Close the browser tab (or let the connection drop) while it runs.
Reopen later and observe: the process is frozen once the kernel buffer filled, and output emitted while detached is gone.

Expected behavior

The child process should keep running — and its output should be retained —
independently of whether a browser client is connected, similar to how
command sessions already buffer output.

Suggested approach

Move PTY draining into the session itself: a session-owned drain task started at session creation that reads PTY output into a capped in-memory buffer (with a monotonic byte counter), independent of clients.
Make terminal_ws a subscriber that tails the session buffer via byte offset (same pattern as command sessions) instead of being the sole reader; reconnecting clients resume from their offset.
On the frontend, re-establish the terminal WebSocket on visibilitychange if the connection died while the tab was hidden (browsers throttle/suspend background tabs and can silently kill the socket).

Environment

Latest main

Originally created by @1-kabir on GitHub (Sep 5, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/251 bug: interactive terminal session freezes long-running processes when the browser client disconnects ### Bug description Interactive (PTY) terminal sessions only drain their PTY output while a browser WebSocket client is attached. If the client disconnects — closed tab, suspended laptop, browser backgrounded/killed — nothing reads the PTY master fd anymore, and the kernel PTY buffer (~64 KB) eventually fills up. Any long-running process attached to the terminal (e.g. a CLI agent, a build, a tail) then blocks on `write()` until a client reconnects. Output produced while detached is also lost beyond the kernel buffer. This makes the terminal unusable as a place to run anything long-lived that produces output. ### To Reproduce 1. Open an interactive terminal session and start a process that emits more than ~64 KB of output over time (e.g. `yes | head -c 100M` or a long build). 2. Close the browser tab (or let the connection drop) while it runs. 3. Reopen later and observe: the process is frozen once the kernel buffer filled, and output emitted while detached is gone. ### Expected behavior The child process should keep running — and its output should be retained — independently of whether a browser client is connected, similar to how command sessions already buffer output. ### Suggested approach - Move PTY draining into the session itself: a session-owned drain task started at session creation that reads PTY output into a capped in-memory buffer (with a monotonic byte counter), independent of clients. - Make `terminal_ws` a subscriber that tails the session buffer via byte offset (same pattern as command sessions) instead of being the sole reader; reconnecting clients resume from their offset. - On the frontend, re-establish the terminal WebSocket on `visibilitychange` if the connection died while the tab was hidden (browsers throttle/suspend background tabs and can silently kill the socket). ### Environment - Latest main ---

bsakaguchi commented

2026-10-18 14:03:31 +00:00

Author

Owner

@owui-terminator[bot] commented on GitHub (Sep 5, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟢 #213 bug: a stalled agent session hangs the chat task forever, and the whole transcript is lost if you kill it
Both reports describe long-running work becoming unusable because a background execution path stops making forward progress and buffered output/state is not preserved when the run is interrupted. While #213 is about an agent session rather than a PTY terminal, it is closely related in the failure mode of indefinite blocking and lost output when the session is no longer actively driven.
by ThalynLabs

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (Sep 5, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟢 [#213](https://github.com/open-webui/computer/issues/213) **bug: a stalled agent session hangs the chat task forever, and the whole transcript is lost if you kill it** *Both reports describe long-running work becoming unusable because a background execution path stops making forward progress and buffered output/state is not preserved when the run is interrupted. While #213 is about an agent session rather than a PTY terminal, it is closely related in the failure mode of indefinite blocking and lost output when the session is no longer actively driven.* *by ThalynLabs* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

bsakaguchi referenced this issue

2026-10-18 14:04:35 +00:00

[PR #163] [MERGED] 0.9.13 #308