The Derived Data path was updated to the new workspace-scoped layout (workspaces/XcodeBuildMCP-<HASH>/DerivedData/...), but the Build Logs path on the same fixture still points to the old top-level logs/ directory. The PR description states logs are also moved into workspace-keyed paths under the shared application support location, so MCP, CLI, and JSON fixtures should consistently reflect the workspace-scoped log path. If logs are now workspace-scoped at runtime, this fixture would drift from rendered output and tests would fail; if not, the two paths in this fixture are inconsistent with the stated change.

Also found at:

• src/snapshot-tests/__fixtures__/cli/simulator/build-and-run--error-compiler.txt:9
• src/snapshot-tests/__fixtures__/cli/device/build--error-wrong-scheme.txt:8
• src/snapshot-tests/__fixtures__/mcp/simulator/test--failure.txt:37

The updated fixture now embeds 'Running tests (N completed, M failure, 0 skipped)' progress lines that depend on test execution timing/ordering. Per the skill's guardrails, volatile values should be normalized in code rather than patched ad hoc into fixtures. If these lines are inherently nondeterministic across runs, they should be filtered or normalized in the snapshot pipeline; otherwise future runs may produce intermittent fixture diffs forcing fixture-only updates to make tests pass.

daemonDirForWorkspaceKey now constructs <tmpdir>/xcodebuildmcp-<12-hex-of-sha256(workspaceRoot)>. On Linux/macOS tmpdir() is typically /tmp, a world-writable directory shared across local users. The 12-hex suffix is fully deterministic from the (often guessable) workspace root path, so a co-resident local user can pre-create the directory (or a symlink at that name) before the victim's daemon starts. ensureSocketDir calls mkdirSync(dir, { recursive: true, mode: 0o700 }), but Node's mkdirSync does not modify mode on an existing directory, so the 0o700 protection is silently bypassed when the path already exists. Combined with removeStaleSocket blindly unlinkSync-ing inside that directory, a local attacker can squat on the path, intercept/disrupt the daemon's IPC socket, or force the daemon to bind into an attacker-controlled location. The previous implementation placed these under ~/.xcodebuildmcp/daemons/<key>, which is inside the user's home directory and not exposed to other local users.

process.kill(pid, 0) with pid <= 0 has special semantics in POSIX: pid 0 signals every process in the caller's process group, and negative pids signal a process group. Passing such values to isPidAlive will not check liveness of a specific process and may return true based on group membership rather than the intended target. Callers using this for live-owner detection during cleanup could incorrectly conclude that a stale/invalid recorded pid (e.g., 0) is still alive and skip cleanup of artifacts indefinitely.

The startup registry lock is acquired at line 186 but is only released inside the server.listen callback (line 433) or via server.on('error') (line 412). If any code between acquisition and server.listen—such as buildDaemonToolCatalogFromManifest (line 270), setSentryRuntimeContext, recordDaemonGaugeMetric, or startDaemonServer—throws, control falls through to the top-level main().catch which exits without releasing the lock. Depending on the lock implementation, this can leave a stale lock that blocks subsequent daemon startups for the workspace.

withDaemonRegistryMutationLock returns null when the bounded busy-wait for the daemon registry lock times out (DAEMON_REGISTRY_LOCK_WAIT_MS = 1s). writeDaemonRegistryEntry checks for this null and throws, but removeDaemonRegistryEntry (lines 286-288) and cleanupWorkspaceDaemonFiles (lines 331-345) discard the return value. Under contention from another MCP server, daemon, or CLI, cleanup will silently no-op, leaving stale registry/socket files behind that can mislead subsequent daemon startup or liveness checks.