2.118.0-beta.72 (darwin-arm64): `supabase --version` blocks forever in open(2), and one stuck process blocks every later invocation

Affected area

Installation

Supabase CLI version

2.118.0-beta.72

Operating system

macOS (Darwin 25.6.0), Apple silicon (darwin-arm64)

Installation method

npm

Command

supabase --version

Actual output

(nothing — the process never exits)

The process sits at 0% CPU. sample shows the main thread blocked in open(2):

Sort by top of stack, same collapsed (when >= 5):
        __openat_nocancel  (in libsystem_kernel.dylib)        798
        __ulock_wait  (in libsystem_kernel.dylib)             798
        __workq_kernreturn  (in libsystem_kernel.dylib)       798

lsof on the stuck process shows only its cwd and the stdout/stderr pipes, with no regular files open.

Expected behavior

It prints 2.118.0-beta.72 and exits, as it does most of the time.

Steps to reproduce

We have not found the trigger for the first hang. Here is what we observed:

1. On a self-hosted macOS arm64 GitHub Actions runner, supabase/setup-cli@v3 with version: 2.118.0-beta.72 ran npm view and npm install in about 2 s. Its follow-up supabase --version never returned, and the job sat in the setup step for 14 minutes until the run was cancelled.
2. While a stuck supabase --version process was alive, every other invocation of the 2.118.0-beta.72 darwin-arm64 binary on the same machine also blocked at startup. That held for --version and --help alike, from cwd / or /tmp, under env -i, with HOME pointed at an empty directory, and with stdin from /dev/null. Each attempt hung until a 10-15 s alarm killed it.
3. During the same window, the 2.117.0 and 2.90.0 binaries on the same machine answered --version immediately.
4. After the stuck processes were killed, supabase --version from 2.118.0-beta.72 answered in about 1 s again.
5. Earlier the same day, the same beta ran db start, start, functions serve and stop on this machine without problems.
6. No process held ~/.supabase/telemetry.json or ~/.supabase/traces/*.ndjson open while the hang was happening.

Because a new process from any cwd, env or HOME blocks in open(2) only while another instance is stuck, the binary seems to open a machine-global path that can block, such as a FIFO or an exclusively locked file, before it prints anything.

Additional context

We tried the beta because it includes #6697, the fix for the quadratic statement splitter in #6686, which makes db start take about 10 minutes on a 2.9 MB single-statement migration in 2.110.0 through 2.117.0. We reverted our CI to 2.90.0 because a hang like this can hold a single self-hosted runner indefinitely.