🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

const file = isWindows ? (process.env.ComSpec ?? "cmd.exe") : "launchctl";
return await execFileUtf8(file, fileArgs, isWindows ? { windowsHide: true } : {});

import path from "node:path";

const launchctlPath = process.platform === "darwin" ? "/bin/launchctl" : "launchctl";

return await execFileUtf8(
  launchctlPath,
  args,
  {
    ​// Optionally restrict env to avoid PATH-based resolution entirely
    env: {
      ...process.env,
      PATH: "/usr/bin:/bin:/usr/sbin:/sbin",
    },
  }
);

Analyzed PR: #72616 at commit 1c6c538

_{Last updated on: 2026-04-27T05:41:10Z}

Greptile Summary

This PR detects and repairs the macOS LaunchAgent "split-brain" state — where the plist is installed and the gateway listener/RPC is healthy but launchd no longer has the job loaded — by surfacing a new missingSupervision runtime flag and invoking recoverInstalledLaunchAgent (bootstrap + kickstart) before falling back to unmanaged restart. It also removes a pre-existing bug in the doctor flow where the isLaunchAgentListed gate prevented repair from firing in the exact split-brain condition it was meant to catch.

• The priority inversion in lifecycle.ts (recoverInstalledLaunchAgent now runs before restartGatewayWithoutServiceManager) can leave a launchd respawn loop when an unmanaged process is already holding the port at restart time. kickstart -k returns 0 immediately after launchd spawns the new process; the new process exits on port-bind failure; launchd respawns repeatedly. The unmanaged process is never terminated because signalVerifiedGatewayPidSync is no longer called in this path. The fix is to terminate any verified listener PIDs before calling recoverInstalledLaunchAgent.

Confidence Score: 3/5

The PR contains a P1 logic issue in the restart path that can leave a launchd respawn loop when an unmanaged gateway process is still alive on the port.

One P1 finding (launchd respawn loop due to priority inversion in lifecycle.ts) pulls the score to 3. The rest of the changes — the missingSupervision type/hint plumbing, the isLaunchAgentListed removal in the doctor flow, and the new regression tests — are clean and correct.

src/cli/daemon-cli/lifecycle.ts — priority inversion of launchd repair vs. unmanaged restart needs a pre-termination guard for existing unmanaged PIDs.

This is a comment left during a code review.
Path: src/cli/daemon-cli/lifecycle.ts
Line: 204-215

Comment:
**Launchd respawn loop when unmanaged process holds the port**

When `onNotLoaded` fires and an unmanaged gateway process is already listening on the port (the split-brain state with pid 4200 in the updated test), calling `recoverInstalledLaunchAgent` first runs `launchctl bootstrap` + `kickstart -k`. `kickstart` returns 0 as soon as launchd spawns the new process, regardless of whether it stays alive. The new launchd-managed process then fails to bind the port (still held by the unmanaged process) and exits. launchd detects the exit and immediately respawns — creating a respawn loop.

The unmanaged process (pid 4200) is never signaled because `signalVerifiedGatewayPidSync` is no longer called in this path. `waitForGatewayHealthyRestart` may then report success by probing the unmanaged process's port, masking the respawn loop from the user.

The previous priority (SIGUSR1 to the unmanaged process first, launchd repair only when no listener exists) avoided this scenario by cleanly handing off before touching launchd. A guard that terminates any verified listener PIDs before bootstrapping would prevent the port-conflict respawn loop.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(daemon): reconcile macOS LaunchAgent..." | Re-trigger Greptile}