terminal-size

When both stdout and stderr are redirected and / are unset, falls through to . The current implementation opens and constructs a , but closes neither descriptor deterministically. On Linux, libuv normally reopens the TTY before attaching it to the stream handle. Consequently, each call can retain both the descriptor returned by and libuv’s reopened descriptor. One concrete trigger is an ink-based application running in a Docker container with a controlling TTY while its stdout and stderr are redirected inside the container. Ink falls back to terminal-size when terminal dimensions are unavailable and may invoke it repeatedly during rendering. Reproduction Using 4.0.1 on Node.js 24.18.0, Debian 12: Observed: The descriptors remained open after forced garbage collection and event-loop turns. Repeated calls can therefore exhaust the process’s descriptor limit and interfere with unrelated I/O. Cleanup complication The straightforward cleanup attempted in PR #27 was: 1. Retain the descriptor passed to . 2. Call . 3. Close the retained descriptor in a block. That is unsafe under descriptor pressure. libuv normally reopens the TTY, but if reopening fails, it retains the supplied descriptor. then closes that descriptor synchronously. Another native thread can reuse its number before the block calls , causing the latter to close an unrelated descriptor. The documented Node.js API does not expose whether libuv duplicated or retained the supplied descriptor, so the caller cannot safely decide which descriptors it still owns. Expected behavior Repeated calls should: Return the controlling terminal’s dimensions. Keep the process’s descriptor count stable. Never close unrelated descriptors under descriptor pressure. The regression test should run a redirected child inside a real pseudo-terminal in Linux CI rather than skipping when the CI process lacks a controlling TTY. This issue is Linux-specific. macOS follows a different libuv path and should be handled separately.