Starting April 2026, the CodeQL Action will skip computing file coverage information on pull requests to improve analysis performance. File coverage information will still be computed on non-PR analyses. To opt out of this change, create a custom repository property with the name `github-codeql-file-coverage-on-prs` and the type "True/false", then set this property to `true` in the repository's settings.

Starting April 2026, the CodeQL Action will skip computing file coverage information on pull requests to improve analysis performance. File coverage information will still be computed on non-PR analyses. To opt out of this change, create a custom repository property with the name `github-codeql-file-coverage-on-prs` and the type "True/false", then set this property to `true` in the repository's settings.

The fixture now includes seven 'Running tests (N completed, M failure, ...)' progress lines. These lines depend on test execution timing/ordering and are not normalized like other volatile values (timestamps, PIDs, hashes). Per the skill guardrails, volatile values should be normalized in code rather than baked into fixtures, otherwise the snapshot will be flaky across runs. The Derived Data path change is expected (workspace-scoped path), but these progress lines are a separate concern.

This fixture update mixes two unrelated changes: the workspace-scoped Derived Data path rename, and a substantive change in test discovery/failure counts (52→57 discovered, 2→4 failures, with two new failing test entries). The PR description scopes fixture churn to 'new workspace-scoped paths', but new failing tests and discovered counts indicate a behavior change in the underlying test suite or runner output that is not explained. Per the skill guardrail 'Fixture updates map to intentional behavior changes' and 'Do not update fixtures only to make tests pass', the reviewer cannot verify whether these added failures are intentional or accidental snapshot drift.

After sending SIGTERM and waiting 500ms, forceStopDaemon calls cleanupWorkspaceDaemonFiles with pid set but without allowLiveOwner=true. In canRemoveRegistryEntry, when allowLiveOwner is not true the function returns !isPidAlive(entry.pid); if the daemon hasn't yet exited (500ms is short for a graceful SIGTERM shutdown), removeRegistryAtPathIfOwned returns null and neither the registry entry nor the socket is removed. The previous implementation unconditionally called removeStaleSocket(socketPath), so this is a behavioral regression: ensureDaemonRunning will then proceed to startDaemonBackground while the old socket file still exists, which can cause the new daemon's bind() to fail with EADDRINUSE and leave the workspace unable to start a daemon.

After sending SIGTERM and waiting 500ms, forceStopDaemon calls cleanupWorkspaceDaemonFiles with pid set but without allowLiveOwner=true. In canRemoveRegistryEntry, when allowLiveOwner is not true the function returns !isPidAlive(entry.pid); if the daemon hasn't yet exited (500ms is short for a graceful SIGTERM shutdown), removeRegistryAtPathIfOwned returns null and neither the registry entry nor the socket is removed. The previous implementation unconditionally called removeStaleSocket(socketPath), so this is a behavioral regression: ensureDaemonRunning will then proceed to startDaemonBackground while the old socket file still exists, which can cause the new daemon's bind() to fail with EADDRINUSE and leave the workspace unable to start a daemon.

The 5s forced-shutdown timer previously called the synchronous cleanupWorkspaceDaemonFiles and then exited. It now awaits the async cleanupOwnedWorkspaceFilesystemArtifacts via .finally() with no timeout. If that promise hangs (e.g., a stuck filesystem lock acquired in fs-lock-shared / workspace-filesystem-lifecycle), the daemon will never exit, defeating the purpose of the forced-shutdown path and causing process leaks across daemon restarts.

The 5s forced-shutdown timer previously called the synchronous cleanupWorkspaceDaemonFiles and then exited. It now awaits the async cleanupOwnedWorkspaceFilesystemArtifacts via .finally() with no timeout. If that promise hangs (e.g., a stuck filesystem lock acquired in fs-lock-shared / workspace-filesystem-lifecycle), the daemon will never exit, defeating the purpose of the forced-shutdown path and causing process leaks across daemon restarts.

`daemonRunDir()` now returns `os.tmpdir()` (typically `/tmp` on Linux, a world-writable shared directory), and `daemonDirForWorkspaceKey` builds a predictable path `xcodebuildmcp-<12-hex>` under it. Because `workspaceKeyForRoot` is a deterministic SHA-256 of the workspace root path, any local user can predict the directory name and pre-create it (or create it as a symlink) before the daemon starts. The directory creator in `ensureSocketDir` uses `existsSync`+`mkdirSync` (TOCTOU) and will not enforce ownership/mode if the directory already exists, which can lead to the daemon binding its UNIX socket inside an attacker-controlled directory and `removeStaleSocket` unlinking attacker-chosen files. Previously the directory lived under `~/.xcodebuildmcp` which was not shared between users.

`daemonRunDir()` now returns `os.tmpdir()` (typically `/tmp` on Linux, a world-writable shared directory), and `daemonDirForWorkspaceKey` builds a predictable path `xcodebuildmcp-<12-hex>` under it. Because `workspaceKeyForRoot` is a deterministic SHA-256 of the workspace root path, any local user can predict the directory name and pre-create it (or create it as a symlink) before the daemon starts. The directory creator in `ensureSocketDir` uses `existsSync`+`mkdirSync` (TOCTOU) and will not enforce ownership/mode if the directory already exists, which can lead to the daemon binding its UNIX socket inside an attacker-controlled directory and `removeStaleSocket` unlinking attacker-chosen files. Previously the directory lived under `~/.xcodebuildmcp` which was not shared between users.

shouldRecoverLockDir refuses to recover an expired lock if `isPidAlive(staleOwner.pid)` returns true. On Linux/macOS, PIDs are recycled, so an unrelated long-running process inheriting the recorded PID will keep the expired lock un-recoverable forever. Every future acquirer for that workspace will fail to acquire the lock, producing a denial-of-service for cleanup/daemon operations. Consider also comparing process start time or the owner token before honoring `isPidAlive`.