macOS: sfw-free proxy can busy-loop at ~80% CPU and never exit after mid-request network interruption; copies accumulate

[amotivv]

Summary

On macOS, after a mid-request network interruption, sfw-free proxy processes can get stuck in a persistent CPU spin and never exit. I observed 17 accumulated proxy processes at ~80% CPU each after overnight sleep/wake cycles. I could not reproduce the spin on Linux, which points toward a possible macOS/kqueue-specific event-loop issue.

I did a fair amount of digging (details + measurements below) and it looks like a libuv event-loop spin on a dead/half-closed socket that is specific to macOS (kqueue) I could not reproduce it on Linux. I have not been able to pin the exact line.

Possibly related: #38 (runaway processes when npm/npx are globally wrapped) and #25 (signal/lifecycle handling).

Environment

• macOS (Apple Silicon, arm64)
• sfw (npm wrapper) v2.0.6
• sfw-free binary v1.10.0 at the time of the incident; I separately confirmed the cited source is unchanged through v1.12.0 (current latest), so it still applies
• npm/npx globally wrapped via a PATH shim, so every package-manager call routes through sfw (same setup as Runaway process loop when npm/npx are globally wrapped by sfw on Ubuntu (Remote SSH / agent workflow) #38)
• Trigger: a background process that ran npm view <pkg>@latest version --prefer-online repeatedly (≈ hourly in this incident), across overnight sleep/wake cycles

Symptoms (observed)

17 sfw-free proxy processes (the Node SEA that spawns the package manager) alive simultaneously. Activity Monitor showed all 17 at 79.6–82.0% CPU; a few rows (instantaneous %CPU and accumulated CPU time):

%CPU   CPU TIME    PROCESS
82.0   17:07.89    sfw-free-macos-arm64
81.7   12:48.21    sfw-free-macos-arm64
81.2   25:18.32    sfw-free-macos-arm64
…      (17 rows total)

ps confirmed all 17 were state R (on-CPU), on the same TTY, ~250 MB RSS, each running:

sfw-free-macos-arm64 npm view <pkg>@latest version --prefer-online

• Start times were spread ~1/hour across ~19 hours (12:44 PM → 8:05 AM the next day), matching the update-check interval plus overnight sleep/wake.
• At that moment the machine was at 97% user / 0% idle.
• The same command run fresh completes in ~2.7s, so this is a state-dependent hang.

[amotivv]

Follow-up: raw data from a live capture. The processes recurred and I caught them while still running, so I captured a CPU sample, per-thread CPU, and lsof before killing them. Posting the observations verbatim and leaving interpretation to you.

Environment: macOS (Apple Silicon), sfw-free v1.12.0, npm/npx globally wrapped via a PATH shim; the stuck command was a background npm view @anthropic-ai/claude-code@latest version --prefer-online.

1. The processes (ps)

Four processes, parent PID 1 (launchd), TTY s008, state R:

PID    %CPU   ELAPSED     COMMAND
77740  99.1   06:56:18    sfw-free-macos-arm64 npm view @anthropic-ai/claude-code@latest version --prefer-online
77776  101.0  05:49:29    (same)
77809  99.1   04:42:15    (same)
77843  99.7   03:15:41    (same)

2. Per-thread CPU (ps -M 77740)

One thread held the CPU; the rest were idle:

%CPU  STAT          STIME     UTIME
99.3  R           0:52.37  48:03.09   ← thread 1
 0.5  S           0:00.21   0:09.90
 0.4  S           0:00.22   0:09.68
 0.4  S           0:00.22   0:09.87
 0.4  S           0:00.22   0:10.08
 0.0  S  (six more threads at 0:00.00)

3. CPU sample (sample 77740 5)

3931 samples on thread 1. The single heaviest call path, with each frame's sample count (verbatim symbol names from the sample output):

3931  node::Start
3931  node::NodeMainInstance::Run()
3931  node::SpinEventLoopInternal(node::Environment*)
3930  uv_run
3930  uv__run_check
3925  node::Environment::CheckImmediate(uv_check_s*)
3918  node::InternalMakeCallback(...)
3888  v8::Function::Call(...)
2910  v8::internal::Invoke(...)
2909  v8::internal::Isolate::ReportPendingMessages(bool)
2875  v8::internal::MessageHandler::ReportMessage(...)
2838  node::errors::TriggerUncaughtException(...)
2717  node::inspector::(anonymous namespace)::InspectorConsoleCall(...)
   (… JS frames, unsymbolized …)
1188  v8::internal::Accessors::ErrorStackGetter(...)
1182  v8::internal::ErrorUtils::GetFormattedStack(...)
1037  v8::internal::ErrorUtils::FormatStackTrace(...)
1032  node::PrepareStackTraceCallback(...)
   (… below this: v8::internal::SeqString::Truncate, ExternalOneByteString::Get,
      String::SlowEquals, String::ComputeAndSetRawHash, etc.)

A second process (sample 77843 3) showed the same frames in the same order (counts: CheckImmediate 2273, TriggerUncaughtException 1646, InspectorConsoleCall 1582, ErrorStackGetter 665, FormatStackTrace 587, PrepareStackTraceCallback 584).

4. Open files / sockets (lsof -nP -p 77740)

FD   TYPE     NAME
3u   KQUEUE   count=0, state=0x8
4    PIPE     0xd0345bf74a14b830 -> 0xbd2971558d7aaf1c
5    PIPE     0xbd2971558d7aaf1c -> 0xd0345bf74a14b830
7u   KQUEUE   count=0, state=0xa
9u   KQUEUE   count=1, state=0x8
13u  IPv4 TCP 127.0.0.1:50829 (LISTEN)
14u  IPv4 TCP 127.0.0.1:50829->127.0.0.1:60056 (CLOSED)
16u  IPv4 TCP 127.0.0.1:50829->127.0.0.1:50895 (CLOSED)
18u  IPv4 TCP 127.0.0.1:50829->127.0.0.1:53225 (CLOSED)

I have the full sample output and lsof for both processes and can attach them. Happy to capture anything else (e.g. dtruss) if it recurs.