macOS sandbox blocks ps-backed recording process identity #2376

Activity

1. thymikee commented on Oct 9, 2026

   

   thymikee

   on Oct 9, 2026

   Member

   More actions

   Decision: one process-identity direction for this and #3291: move off ps to appandflow/unique-pid (#2377 was closed in its favor).

   Before switching packages/host-kit/src/internal/host-process.ts, check:

   • packaging on macOS, Linux and Windows (prebuilt binaries, install without a toolchain),
   • zombie processes and reused PIDs, plus the unknown and permission-denied cases, as typed outcomes,
   • the recording-owner guards still hold. An identity token doesn't make sending a signal atomic, so keep the existing guard order.

   #3291's Windows log-truncation failure is independent and shouldn't wait for this.
2. thymikee

   added

   ready-for-agent

   on Oct 9, 2026
3. andrea689 commented on Nov 11, 2026

   

   andrea689

   on Nov 11, 2026

   More actions

   The same ps refusal now breaks the daemon itself under sandbox-exec, not only recording. Seen on 0.21.36 (macOS 27.2, Node 22); 0.21.19 worked under the same profile.

   The client takes a daemon it spawned as ready only once daemon.json has a processStartTime equal to the one it reads itself, and both come from /bin/ps -o lstart=. Under the sandbox both are null, so every command stalls and fails:

   $ sandbox-exec -p '(version 1)(allow default)' /bin/ps -o lstart= -p 1
   sandbox-exec: execvp() of '/bin/ps' failed: Operation not permitted
   
   $ AGENT_DEVICE_STATE_DIR=/tmp/ad-sbx sandbox-exec -p '(version 1)(allow default)' agent-device devices --platform ios
   Error (COMMAND_FAILED): Failed to start daemon
   Hint: The daemon is alive but made no startup progress for 60 s. The host can be overloaded. Retry once the host load drops; ...
   # after 61 s
   
   $ AGENT_DEVICE_STATE_DIR=/tmp/ad-sbx agent-device daemon stop
   Error (COMMAND_FAILED): Daemon retirement could not be confirmed.
   # the daemon keeps running
   

   Two things made it slow to diagnose: the hint points at host load, and neither the error nor daemon.log says that ps was refused. Surfacing the EPERM there would help until the move to unique-pid lands.

   A workaround that works for us with 0.21.36 under the sandbox, in case it helps someone meanwhile: a copy of /bin/ps re-signed ad hoc (cp /bin/ps <dir>/ps && codesign --force --sign - <dir>/ps; a plain copy is killed because of the original's entitlements), made outside the sandbox, plus NODE_OPTIONS=--require=<preload> with a preload that points child_process.spawn/spawnSync of /bin/ps at it. A profile that restricts writes under ~/.agent-device also has to allow the new <lock>.reclaim.lock guard that each lock release creates beside the runner cache's lock.
4. thymikee

   added

   bugSomething isn't workingSomething isn't working

   on Nov 12, 2026
5. thymikee commented on Nov 12, 2026

   

   thymikee

   on Nov 12, 2026

   Member

   More actions

   Triage: bug; the new report extends #2376 to daemon startup and retirement. On current main, isLaunchedDaemon requires a non-null start identity, while the shared process reader turns a refused ps execution into null. The existing unique-pid direction still applies; startup and stop must preserve ownership checks and expose unavailable identity evidence instead of diagnosing host load. Thanks for the version comparison and sandbox reproduction.