PR #391 #1113
codeql
on: dynamic
Matrix: analyze
Annotations
8 warnings
|
Analyze (python)
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.
|
|
Analyze (javascript-typescript)
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.
|
|
Test failure fixture adds new failures and changes counts without retention path log update:
src/snapshot-tests/__fixtures__/mcp/simulator/test--failure.txt#L9
The fixture now reports 4 failures (was 2) and 57 discovered tests (was 52), and adds two new failure entries plus a workspace-scoped DerivedData path. Per the skill guardrails, fixture updates must map to intentional behavior changes and MCP/CLI/JSON fixtures must stay aligned. The change to test counts/failures appears unrelated to the workspace filesystem cleanup PR's stated scope (workspace path changes), suggesting either a fixture-only update to make tests pass or an unintentional change in the underlying test suite. Verify the corresponding CLI and JSON fixtures for `simulator/test--failure` reflect the same new failures and counts; otherwise the envelopes are misaligned.
|
|
forceStopDaemon may leave socket and registry in place when process hasn't exited within 500ms:
src/cli/daemon-control.ts#L53
forceStopDaemon sends SIGTERM, waits only 500ms, then calls cleanupWorkspaceDaemonFiles without allowLiveOwner: true. In daemon-registry.ts, canRemoveRegistryEntry requires !isPidAlive(entry.pid) when allowLiveOwner is not set, so if the daemon hasn't died yet the registry entry and socket file are not removed. Since forceStopDaemon's documented purpose is to remove the stale socket after a version-mismatch force-stop, callers (e.g. ensureDaemonRunning) may immediately try to start a new daemon while the old socket is still present, defeating the cleanup.
|
|
[JYJ-UYW] forceStopDaemon may leave socket and registry in place when process hasn't exited within 500ms (additional location):
src/daemon.ts#L334
forceStopDaemon sends SIGTERM, waits only 500ms, then calls cleanupWorkspaceDaemonFiles without allowLiveOwner: true. In daemon-registry.ts, canRemoveRegistryEntry requires !isPidAlive(entry.pid) when allowLiveOwner is not set, so if the daemon hasn't died yet the registry entry and socket file are not removed. Since forceStopDaemon's documented purpose is to remove the stale socket after a version-mismatch force-stop, callers (e.g. ensureDaemonRunning) may immediately try to start a new daemon while the old socket is still present, defeating the cleanup.
|
|
ensureSocketDir TOCTOU lets a pre-existing directory bypass the 0o700 mode:
src/daemon/socket-path.ts#L29
ensureSocketDir() guards mkdirSync with existsSync(dir); if the directory already exists (e.g., created by another local user in the shared tmpdir before the daemon starts) the function returns without enforcing mode 0o700 or verifying ownership. Combined with the move of the socket directory under os.tmpdir() in daemonDirForWorkspaceKey(), a local attacker can pre-create the per-workspace directory world-readable/writable and the daemon will happily place its UNIX socket and registry inside it, exposing IPC traffic.
|
|
runningScheduledSweeps lock leaks when sweep promise is never created:
src/utils/workspace-filesystem-lifecycle.ts#L471
In scheduleWorkspaceFilesystemLifecycleSweep, runningScheduledSweeps.add(scheduleKey) is called synchronously, but the corresponding delete only fires inside the setTimeout's .finally(). If the timer is cancelled (e.g. process shutdown before delay elapses) or if runWorkspaceFilesystemLifecycleSweep throws synchronously before returning a promise, the scheduleKey is never removed and all future scheduling for that workspace/logDir is silently blocked for the lifetime of the process.
|
|
[JPM-S8N] runningScheduledSweeps lock leaks when sweep promise is never created (additional location):
src/utils/fs-lock.ts#L138
In scheduleWorkspaceFilesystemLifecycleSweep, runningScheduledSweeps.add(scheduleKey) is called synchronously, but the corresponding delete only fires inside the setTimeout's .finally(). If the timer is cancelled (e.g. process shutdown before delay elapses) or if runWorkspaceFilesystemLifecycleSweep throws synchronously before returning a promise, the scheduleKey is never removed and all future scheduling for that workspace/logDir is silently blocked for the lifetime of the process.
|