daemonDirForWorkspaceKey places the socket directory under tmpdir() (typically /tmp), which is writable by any local user. The workspace hash is deterministic from a path that may be predictable (e.g., /Users/<name>/projects/<name>), so a local attacker can pre-create xcodebuildmcp-<hash> as a symlink targeting an attacker-controlled directory before the daemon starts. mkdirSync with recursive: true silently succeeds when the path already exists, including when it is a symlink to an existing directory. Although validateSocketDir rejects symlinks afterwards via lstatSync, the daemon will refuse to start while the attacker has effectively performed a denial-of-service; if symlink target is owned by the user and not a symlink itself (e.g., the user's ~/.ssh), the ownership check passes and chmodSync may then alter permissions on that target.

The hunk increases tests.discovered.total from 52 to 57, but the visible items list in the surrounding context shows no corresponding additions of five new test entries. If the underlying test count did not actually grow by five, this fixture change would be a snapshot-only patch unrelated to the workspace filesystem cleanup behavior change, which violates the guardrail that fixture updates must map to intentional behavior changes and stay aligned with structured output. Reviewers should confirm the items array elsewhere in the fixture grew by exactly 5 entries; otherwise this is a fixture patched only to make tests pass.

validateSocketDir calls statSync(dir) then chmodSync(dir, 0o700) if permissions are too loose. Between these calls, a local attacker who can win the race could swap the path to a symlink (or replace the directory) so the chmod applies to a different filesystem object owned by the same user. Combined with the predictable path under tmpdir(), this enables tampering with the permissions of arbitrary user-owned directories. Using fchmod on an opened file descriptor (with O_NOFOLLOW) would close the window.

Also found at:

• src/utils/fs-lock.ts:113-121

buildSchedulePreKey-based skip in scheduleWorkspaceFilesystemLifecycleSweep reads lastScheduledAtByPreKey but that map is only updated after a non-skipped sweep completes. Because the entry is set at completedAt (after the schedule delay plus sweep duration), and the same value is also used to short-circuit future schedule calls, this is benign — but the pre-key check uses options.now ?? Date.now() while the post-completion write uses Date.now(); if a caller passes a fixed options.now in the past for tests, the cooldown check can incorrectly skip indefinitely. This can cause scheduled sweeps to be silently dropped in test or time-controlled environments.

Also found at:

• src/utils/workspace-filesystem-lifecycle.ts:426-444

The previous implementation always called removeStaleSocket(socketPath) at the end of forceStopDaemon, ensuring an orphaned socket file would be cleaned up even when no registry entry existed. The new implementation throws early when findDaemonRegistryEntryBySocketPath returns null, so stale sockets without a matching registry entry are never cleaned up by this path. This can leave orphaned socket files on disk that prevent subsequent daemon startup from binding to the expected path.

Also found at:

• src/cli/daemon-control.ts:91-95

daemonRunDir() defaults to os.tmpdir() (typically /tmp, shared/world-writable with sticky bit), and daemonDirForWorkspaceKey produces a deterministic name xcodebuildmcp-<12-hex> derived from the workspace path hash. A local unprivileged attacker who can predict or enumerate workspace hashes can pre-create that directory under their own UID before the daemon starts. ensureSocketDir will then skip mkdirSync (because existsSync is true), and validateSocketDir will throw on the uid mismatch, preventing the daemon from ever starting for that workspace. The validation correctly defends against symlink/uid hijacking of an existing dir, but the predictable name in a shared directory still allows trivial denial-of-service against any user on a multi-tenant host.

Also found at:

• src/daemon/socket-path.ts:89-95

restoreQuarantinedLockDir swallows rename errors and intentionally leaves the quarantined directory in place when restoration fails. Over time, repeated contention failures (e.g., another contender created a new lockDir before the validation rejected our recovery) accumulate '.{name}.stale.{pid}.{uuid}' directories under the lock parent with no cleanup path, causing unbounded disk usage in long-lived workspaces.

Also found at:

• src/utils/fs-lock.ts:184-191

normalizeWorkspaceKey only rejects empty strings and forward/back slashes, but does not reject '..', '.', null bytes, or other characters that can affect path resolution on some platforms. If a workspace key of '..' is ever passed in, path.join will resolve the workspace root to the parent of the workspaces directory, allowing cleanup logic to operate outside the intended workspace tree. The user-visible consequence is potential deletion or lock contention on unintended directories if an attacker or buggy caller controls the workspace key.

process.kill(pid, 0) returns EPERM when the PID exists but belongs to another user/process the caller cannot signal. The function correctly treats this as 'alive' (only ESRCH returns false), but on systems where PID reuse occurs across users, an unrelated process owned by another user could be considered a live workspace-owned helper. Given the skill's emphasis on 'ownership checks' for multi-process cleanup, this liveness primitive alone cannot establish ownership — callers must combine it with workspace ownership verification, otherwise stale helpers owned by other users may be treated as alive and never reconciled.

validateSocketDir lazily chmods the directory to 0o700 only when it detects loose perms (stat.mode & 0o077 !== 0). If a previous run (or external actor with same UID) left the directory world/group-readable, any socket, log, or daemon.json that was created during that window may already have been observable. The fix corrects future state but does not audit or roll prior contents. Consider failing closed (refusing to start) when perms are unexpectedly loose, instead of silently repairing.