Greptile Summary

This PR addresses two clanker review findings from the prior kickstart PR: it replaces the fixed sleep 1 race in the detached handoff helper with a proper PID-polling loop, and it gates the enable + bootstrap recovery path on isLaunchctlNotLoaded() so unrelated kickstart errors are surfaced directly rather than being masked by a secondary bootstrap failure. The new GatewayServiceRestartResult discriminated union cleanly propagates the "scheduled" vs "completed" distinction up through the service abstraction and into the CLI restart path.

Key changes:

• launchd-restart-handoff.ts: shared waitForCallerPid snippet replaces sleep 1 (kickstart) and the old attempt-capped loop (start-after-exit); both modes now poll kill -0 $caller_pid at 0.1 s intervals
• launchd.ts: isLaunchctlNotLoaded guard added before the enable + bootstrap fallback; restartLaunchAgent returns GatewayServiceRestartResult
• lifecycle-core.ts: "scheduled" outcome short-circuits post-restart health checks and emits a distinct JSON result
• schtasks.ts, systemd.ts: updated to return { outcome: "completed" } to satisfy the new type

Notable concern:
The original start-after-exit implementation had a deliberate 100-attempt (~10 s) cap on the PID-poll loop to prevent a runaway detached helper if the caller never exits. The refactored shared snippet removes that cap entirely. In normal operation both callers (restartGatewayProcessWithFreshPid and restartLaunchAgent) pass process.pid and exit promptly, so this is benign in practice — but the safeguard was intentional and its removal is unexplained.

Confidence Score: 4/5

• Safe to merge with a low-risk regression: the removed 100-attempt cap leaves both detached helper modes with an unbounded poll loop, but both callers reliably pass a valid PID that exits promptly in practice.
• The core logic fixes are correct and well-tested. The isLaunchctlNotLoaded guard cleanly addresses Bug 2, and the PID-polling approach for Bug 1 is sound. The one substantive concern is the silent removal of the timeout cap that was deliberately added to start-after-exit — it leaves an edge-case infinite loop potential in the detached shell helper. This is not a merge-blocker but is worth restoring for robustness.
• src/daemon/launchd-restart-handoff.ts — the shared waitForCallerPid loop has no upper-bound on iterations; consider restoring the 100-attempt safety cap.

This is a comment left during a code review.
Path: src/daemon/launchd-restart-handoff.ts
Line: 67-69

Comment:
**Unbounded spin loop — timeout guard was intentionally removed**

The previous `start-after-exit` implementation had an explicit 100-attempt (~10 s) safety cap:

```shell
attempts=0
while kill -0 "$wait_pid" >/dev/null 2>&1; do
  attempts=$((attempts + 1))
  if [ "$attempts" -ge 100 ]; then
    break
  fi
  sleep 0.1
done
```

By sharing a single `waitForCallerPid` snippet between both modes, that cap is gone. If the caller process never exits (hung signal handler, unexpected blocking, or even PID reuse in a long-lived container), the detached helper will spin in `sleep 0.1` forever — accumulating zombie helper processes with no self-termination path.

In normal operation the caller exits quickly, so this is benign; but the original cap was a deliberate defensive measure. Consider restoring a maximum iteration guard, e.g.:

```shell
wait_pid="$4"
if [ -n "$wait_pid" ] && [ "$wait_pid" -gt 1 ] 2>/dev/null; then
  attempts=0
  while kill -0 "$wait_pid" >/dev/null 2>&1; do
    attempts=$((attempts + 1))
    if [ "$attempts" -ge 100 ]; then
      break
    fi
    sleep 0.1
  done
fi
```

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

---

This is a comment left during a code review.
Path: src/daemon/launchd-restart-handoff.test.ts
Line: 18-43

Comment:
**`start-after-exit` mode has no test coverage here**

The new `launchd-restart-handoff.test.ts` only exercises the `kickstart` mode. Because the `waitForCallerPid` snippet is now shared between both modes, it would be worth adding a parallel test for `mode: "start-after-exit"` to confirm:
- `args[2]` is `"openclaw-launchd-restart-handoff"` (same sentinel)
- `args[6]` carries the `waitForPid` value
- The generated script includes `launchctl start` (not `kickstart`)
- `sleep 1` is absent

This guards against accidental divergence if the two branches are ever split again.

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

_{Last reviewed commit: 838c528}