Repository navigation
supabase status spins at ~160% CPU forever when stdout and stderr share a pipe whose reader closes early #6846
Description
Environment
- Supabase CLI 2.116.0 (npm
supabase,@supabase/cli-darwin-arm64); also observed on 2.118.0 - macOS 27.0 (26A428), Apple Silicon (arm64)
- Local stack running (
supabase start)
Steps to reproduce
npx supabase status 2>&1 | head -3
Expected
head prints three lines and exits; the CLI receives EPIPE/SIGPIPE on its next write and exits.
Actual
head exits, but the CLI process never does. It stays at 157-161% CPU until killed. sample shows the main thread looping in kevent64. Because the shell waits on every member of a pipeline, the command never completes. One background invocation ran for 14 hours before it was noticed.
Measurements (each run killed by a watchdog after 15-25 s)
The hang requires both stdout and stderr in the same pipe, with a reader that closes before the CLI has finished writing. Piping only one stream, or draining everything, exits normally. Setting SUPABASE_NO_UPDATE_NOTIFIER=1 does not change the result.
Suggested fix
Exit (or stop writing) when a write to stdout or stderr fails with EPIPE, rather than retrying in the event loop.
Workaround
Capture the whole output first (X=$(supabase status -o json 2>/dev/null)) or redirect to a file, then read that.
Activity
7ttp commentedon Sep 27, 2026
hey @dzbot92 thanks for this! 💚
Couldn’t reproduce this locally on macOS 26.6.2, so the macOS version difference might be relevant
could you share a gist of the full sample output from the hanging process?
yannf86 commentedon Oct 6, 2026
Reproduced on macOS 27.0 (26A428), Apple Silicon, Homebrew CLI 2.118.0 and 2.119.0. Given that it didn't reproduce on 26.6.2, the macOS version does look relevant.
Our trigger was
supabase db query --linked "..." 2>&1 | jq -c ..--linkedprintsInitialising login role...on stderr, jq stops withparse error: Invalid numeric literal at line 1, column 13, and the CLI keeps spinning at ~155% CPU. One run went unnoticed for 8 hours (12.5 h of CPU time).Measurements, each run killed by a watchdog after 20-25 s:
db query --linked "select 1" 2>&1 | jq -c .db query --linked "select 1" 2>/dev/null | truedb query --linked "select 1" 2>/dev/null | jq -c .db query --linked "select 1" 2>/dev/null | cat >/dev/nulldb query --linked "<3000 rows>" 2>/dev/null | head -c 100projects listwith2>&1 | true,2>&1 >/dev/null | true,2>/dev/null | true-o yaml/toml/jsonto tell the processes apartOne correction to the original report: stderr doesn't have to share the pipe. With
db query --linked, stdout alone hangs when the reader has already exited before the CLI's first write (| true). Withprojects listthe same variants hang only some of the time, so it looks timing-dependent.While the process was spinning,
lsofshowed no TCP socket left open (the query had finished): fds 1 and 2 were on the dead pipe.sampleshows the main thread looping throughkevent64,__ulock_wake,os_unfair_lock_lockandclock_gettime. The worker threads are namedBun Pool 0/1andHTTP Client.Full
sampleoutput of that 8-hour process (2.118.0), as requested: https://gist.github.com/yannf86/534758bafa5353fd3530e346271bac3b