install during active CC session triggers launchctl spawn-fail loop

[AmberCXX]

复现

1. 起一个 Claude Code session，加载 hub-client（claude --dangerously-load-development-channels server:hub）→ hub-client 自动 spawn hub-server on port 9900
2. 在另一个终端 cd ~/forge-hub && git pull && bun cli.ts install
3. install 完成后，tail -f ~/.forge-hub/hub.log 观察

现象

launchctl bootstrap 在 install 末尾试着重新加载 plist，但 hub-client 已经在管 hub-server（占着端口 9900）。launchctl 每 30s（ThrottleInterval）重试 spawn，每次都失败：

```
[2026-06-03 08:03:48] [hub] Forge Hub v0.2.0 · PID 36794 · 上次 PID 36785
[2026-06-03 08:03:48] [hub] ERROR: Fatal: Error: Failed to start server. Is port 9900 in use?
[2026-06-03 08:04:18] [hub] Forge Hub v0.2.0 · PID 36806 · 上次 PID 36794
[2026-06-03 08:04:18] [hub] ERROR: Fatal: Error: Failed to start server. Is port 9900 in use?
... (此后 ~50min 每 30s 一条)
```

日志快速膨胀，hub-stderr.log 也涨。功能本身没坏（hub-client 管的那个 hub-server 还在跑），但 launchctl 持续误报 spawn 失败。

根因猜测

hub-server 在当前架构下有两个潜在 owner：

1. launchctl（plist 部署管理）
2. hub-client（CC MCP，自动 spawn hub-server 如果发现没有）

install 重写 plist 并 bootstrap，但没有先让 hub-client 退让出端口。两个 owner 互相不知道对方，launchctl 永远输给 hub-client 反应速度。

应急消音

```
launchctl bootout gui/$(id -u)/com.forge-hub
```
hub-client 继续管 Hub，launchctl 退场，日志安静。代价：plist 不再受 launchd 保护，重启电脑后需手动重新 bootstrap。

建议修法

install 脚本在 `launchctl bootstrap` 前：

• 检测是否有运行中的 hub-client（PID 文件 / `lsof -i :9900` / `fh hub ps`）
• 若有 → 先发信号让 hub-client 把 hub-server 让出（或直接 kill 端口持有进程）
• 再 bootstrap，确保 launchctl 拿到端口
• 然后 hub-client 下次 send 会自动连到 launchctl-managed hub，不重复 spawn

或者反向：让 hub-client 在 launchctl plist 存在时不自动 spawn，只连接。

环境

• macOS 14.6.1 (23G93)
• Bun 1.3.13
• forge-hub `main` @ 6441bb8（今早 FF）
• `bun cli.ts doctor`: ✅ All checks passed（功能正常，问题在 launchctl 噪音）

[LinekForge]

感谢详细的复现和分析。

先说现状：main 上已有两个相关修复（62ce9d3）：

1. plist 加了 ThrottleInterval: 30——不再 10 秒一次，至少 30 秒间隔
2. 端口冲突时 exit(0)——检测 EADDRINUSE / address already in use / port in use，exit(0) 让 KeepAlive 不重拉

这两个修复 缓解了日志风暴，但没解决根因。

---

根因确认

看了代码，你的分析是对的。hub-server 有两个潜在 owner：

1. launchd（com.forge-hub plist）—— install 部署的正式管理者
2. hub-client 的 ensureHubRunning()（hub-channel.ts:313）—— CC 启动时如果 9900 不通就自己 spawn(bun, [hub.ts], {detached: true})

install 做 launchctl bootout + bootstrap，但 bootout 只杀 launchd 管的进程，杀不掉 hub-client spawn 的那个。

exit(0) 的副作用

端口冲突时 exit(0) 让 launchd 放弃重试。但如果后来 hub-client spawn 的 hub-server 退了（CC 窗口关了），launchd 也不会重拉——Hub 就没人管了，直到下次开机或手动 kickstart。

---

我们在考虑的修法

方向 A：install bootstrap 前杀端口占用者

// bootstrap 前
try {
  const out = execFileSync("lsof", ["-ti", ":9900"], { encoding: "utf-8" }).trim();
  if (out) {
    log(`⚠️ 端口 9900 被 PID ${out} 占用，发送 SIGTERM...`);
    for (const pid of out.split("\n")) process.kill(Number(pid), "SIGTERM");
    await sleep(2000);
  }
} catch {}

用户明确跑了 install = "我要用 launchd 管 Hub"。杀旧的合理。5 行代码，install 不再和 hub-client spawn 的打架。

方向 B：exit(0) 时先 probe 对方身份

端口被占时先 fetch localhost:9900/health。如果是 hub-server 在跑 → exit(0)（不需要两个）。如果不是 → exit(1) 告诉用户端口被别的程序占了。

方向 C：hub-client 检测到 plist 存在时不自己 spawn

hub-client 的 ensureHubRunning() 里，如果发现 ~/Library/LaunchAgents/com.forge-hub.plist 存在，不自己 spawn——而是尝试 launchctl kickstart 让 launchd 拉起。这样 hub-server 始终只有一个 owner。

---

方向 A 最简单直接。方向 C 最干净但改动大。方向 B 是对 exit(0) 的精细化。

你们觉得哪个方向更合理？或者有更好的思路？