The daemon directory is now placed under tmpdir() (typically /tmp, world-writable with sticky bit) using a predictable path xcodebuildmcp-<12-hex-chars>. Combined with ensureSocketDir's existsSync-then-mkdirSync pattern (in this file at lines 77-82), an attacker on a multi-user system could pre-create the directory or a symlink at the predictable path before the daemon starts, bypassing the intended mode: 0o700 and exposing the Unix domain socket to other local users. The previous location under ~/.xcodebuildmcp/daemons/<key> was inside the user's home directory and not subject to this race.

process.kill(0, 0) on POSIX sends signal 0 to every process in the caller's process group, and negative PIDs target a process group rather than a single process. Because isPidAlive does not validate the input, callers passing a stale/zero/negative PID (e.g. from a corrupted registry file) can inadvertently probe or signal unrelated processes, and the function will report 'alive' based on group membership rather than the intended PID. In a cleanup path that uses liveness to decide whether to delete another workspace's artifacts, this can both prevent legitimate cleanup and, if the signal value were ever changed, target unintended processes.

compactWorkspaceKey extracts only the trailing 12-hex-character hash from the workspace key (or hashes the whole key to 12 hex chars) for the daemon directory name, while registryPathForWorkspaceKey and logPathForWorkspaceKey continue using the full workspace key (name + hash). Two workspaces whose name slugs differ but whose path hashes collide in 12 hex chars (~2^48 space) — or where a malicious workspace name is constructed to mimic the -<12hex>compactWorkspaceKeyextracts only the trailing 12-hex-character hash from the workspace key (or hashes the whole key to 12 hex chars) for the daemon directory name, whileregistryPathForWorkspaceKeyandlogPathForWorkspaceKey` continue using the full workspace key (name + hash). Two workspaces whose name slugs differ but whose path hashes collide in 12 hex chars (~2^48 space) — or where a malicious workspace name is constructed to mimic the suffix pattern of another — would share the same daemon directory and socket while having distinct registry/log directories, leading to socket cross-talk while state remains separate.

In scheduleWorkspaceFilesystemLifecycleSweep, resolveOptions(options) is called synchronously and the resulting resolved (with resolved.now fixed at scheduling time) is captured in the setTimeout closure and passed to runWorkspaceFilesystemLifecycleSweep. When the timer fires (after at least WORKSPACE_FILESYSTEM_LIFECYCLE_SCHEDULE_DELAY_MS, possibly much longer under event-loop pressure), the sweep uses this stale now for cooldown checks (shouldSkipForCooldown), minVisibleMs protection in isProtectedLogFile, age expiration (options.now - file.mtimeMs > options.maxAgeMs), and the marker mtime written by touchCleanupMarker. This can cause the marker to be backdated and protection windows to use outdated time, producing slightly incorrect retention decisions and cooldown evaluations.