The setTimeout at line 344 is never cancelled when server.close() completes successfully. If the server closes (line 334) but the subsequent cleanupArtifacts() + flushAndCloseSentry(2000) chain takes longer than 5 seconds (the Sentry flush alone allows up to 2s), the timeout fires and invokes cleanupArtifacts() a second time concurrently with the in-flight cleanup, then calls process.exit(1). This can (a) race two cleanup runs against the same workspace-keyed artifacts/locks, and (b) override the intended exitCode with 1, masking clean shutdowns as failures.

Also found at:

• src/cli/daemon-control.ts:53-57

daemonRunDir() now returns os.tmpdir(), and daemonDirForWorkspaceKey() places the daemon socket under tmpdir()/xcodebuildmcp-<hash>/d.sock. On Linux this resolves to /tmp, which is world-writable and shared across users. The socket directory is created in ensureSocketDir() with mkdirSync({recursive: true, mode: 0o700}), but recursive mkdir does not change permissions on a pre-existing directory. A local attacker who guesses or enumerates the workspace hash can pre-create /tmp/xcodebuildmcp-<hash> with looser permissions before the daemon starts; the daemon will then bind its socket inside an attacker-controlled directory, enabling socket hijacking, MITM of daemon RPC, or command injection through the daemon protocol. The previous implementation placed daemon artifacts under ~/.xcodebuildmcp (line 5 of the pre-diff), which inherited the home directory's restrictive permissions and was not subject to this race.

Also found at:

• src/daemon/socket-path.ts:33-36

process.kill(0, 0) and process.kill(-N, 0) have special semantics on Unix: pid 0 targets the caller's process group and negative pids target a process group, which will typically succeed and cause isPidAlive to return true for invalid/sentinel pids. Some callers (e.g. src/daemon/daemon-registry.ts:219, src/utils/fs-lock.ts:93, src/utils/log-capture/simulator-launch-oslog-sessions.ts:85) do not pre-validate pid > 0, so a corrupted or zero-valued pid record would be considered live and prevent cleanup of stale artifacts — undermining the workspace cleanup ownership boundaries this PR introduces.

In scheduleWorkspaceFilesystemLifecycleSweep, lastScheduledAtByScope and lastScheduledAtByPreKey are only updated after the runningScheduledSweeps.has(scheduleKey) early return. That part is fine, but if a sweep is already running, subsequent calls will keep hitting the running-set early return without ever updating the cooldown timestamp; once the running sweep finishes, the next call will schedule another sweep immediately because the cooldown was never advanced. This can cause back-to-back sweeps under load instead of the intended cooldown spacing.

cleanupOwnedWorkspaceFilesystemArtifacts returns a result with scanned: 0, deleted: 0 and does not invoke pruneKnownLogDirectory or acquire the workspace fs lock. If the caller relies on this shutdown path to also enforce log retention (as the PR description implies), expired/excess logs will accumulate because shutdown skips the prune step entirely. Additionally, daemon cleanup runs without the shared lock, which could race with another process performing a sweep.

buildSchedulePreKey/pre-key cooldown uses options.now ?? Date.now() before resolveOptions runs. If a caller passes a now that resolveOptions would normalize differently (e.g., default), the pre-key cooldown comparison can disagree with the post-resolve scope cooldown comparison, allowing a sweep to be scheduled that would otherwise be cooled down (or vice versa). The two cooldown gates can produce inconsistent decisions for the same call.