Orphaned Runtime Host outlives the desktop app and blocks the next launch

[Astro-Han]

What happened

Killing the desktop app's Electron main process leaves its Runtime Host process running. The next launch — from any worktree sharing the workspace — stops at the startup dialog "旧版 Runtime Host 正在运行 / 另一个 Runtime Host 进程仍占用此工作区" and waits indefinitely for a process whose parent is already gone.

The dialog offers "wait for the current Host to exit", but nothing is going to exit: the Host outlived the app that spawned it and has no remaining supervisor. The only way forward is to find and kill it by hand.

This makes "restart the dev app" unreliable in exactly the situation where it is used most — iterating across worktrees, where the app is stopped by signal rather than by Cmd-Q.

How to reproduce

1. Start the dev app from a worktree: npm start -w @maka/desktop.
2. Let it finish starting so the Runtime Host is up.
3. Kill the Electron main process rather than quitting the app: pkill -f "<worktree>/apps/desktop".
4. Observe that a Runtime Host process from that worktree is still running.
5. Start the dev app again (same or another worktree).
6. Observed: the startup dialog reports a prior Runtime Host holding the workspace and the app never proceeds. In this session it sat there until a 10-minute timeout, then again on a second attempt.

Expected: the Runtime Host exits with the app that owns it, or the next launch reclaims a workspace whose Host has no live parent.

Environment

Maka 0.2.0, dev build, Electron 43.4.1 / Chrome 150, Node 24.18.1, darwin 25.6.0 (arm64), locale zh-CN. Workspace ~/Library/Application Support/Maka Dev/workspaces/default.

Logs, screenshots, or additional context

Diagnostic report captured on the blocked launch:

Surface: startup
Title: 旧版 Runtime Host 正在运行
Description: 另一个 Runtime Host 进程仍占用此工作区。
已运行约 1 分钟
目标: 1
Main process uptime: 12s

Recent main-process logs (2)
[2026-08-28T18:41:38.172Z] LOG [startup] app ready
[2026-08-28T18:41:38.756Z] LOG [shell-env] resolved login-shell PATH (32 entries)

Recent local Runtime Host process exits (0)
<none captured>

Runtime Host
Diagnostics unavailable: Runtime Host diagnostics were unavailable before the app opened

"Recent local Runtime Host process exits (0) — none captured" is consistent with the reading above: the Host did not exit, it was inherited.

Found while capturing before/after recordings for #4105, where it blocked the run twice.

[hydraxman]

take

[hydraxman]

Implementation plan

Problem and impact

A Desktop-spawned ephemeral Runtime Host is detached from the Electron process. Normal quit explicitly retires that owned Host, but an abrupt main-process exit leaves no equivalent ownership signal, so a later Desktop launch can be blocked by the surviving generation.

Required behavior

• A Host spawned for Desktop remains bound to that Desktop launcher and closes if the launcher IPC channel disappears.
• Generic detached launches keep their existing reusable lifetime.
• Authority-supervised launches keep their existing lease-before-close ordering.

Dev design

Add an opt-in launcher-ownership flag at the connect/spawn boundary. Desktop sets it for local candidates. Opted-in detached candidates receive an IPC channel and activate the existing launch-owner guard even when no authority lease descriptor is present; the guard closes the Host on launcher disconnect. The authority lease remains optional and is still released only after Host closure.

Alternatives considered

• Shortening the global idle grace would change CLI and multi-client reuse semantics and still leaves a delay.
• Reclaiming by PID from the next launch risks PID reuse and cannot prove ownership as directly as the inherited IPC channel.
• Binding every detached launch to its caller would break the existing generic detached-host contract, so the behavior is Desktop-only.

Scope / non-goals

No service-managed or remote Host lifecycle changes, no protocol/schema change, and no change to generic detached launch behavior.

Test plan and acceptance criteria

• RED: a launcher-owned detached Host remains connected after its launcher is killed.
• GREEN: the same real-process test observes connection closure and process exit within 5 seconds.
• Existing detached-survival, authority-supervised loss, and post-launcher stderr tests continue to pass.
• Full Runtime Host tests, focused Desktop candidate/manager tests, lint, format, and main-process build pass.

AI-assisted: implementation and test drafting used OpenAI Codex; hydraxman reviewed the design, diff, and verification and remains the human contributor of record.

[hydraxman]

PR #4114 implements the accepted scope.

Acceptance evidence:

• The regression fails on base because the launcher-owned detached Host remains connected.
• The fixed test observes connection closure and process exit after launcher loss.
• Generic detached-host survival, authority-supervised launcher loss, and stderr-after-launcher-exit behavior remain covered.
• Full Runtime Host suite: 1,346 passed, 9 skipped.
• Focused Desktop candidate/manager suite: 54 passed.
• Desktop main-process build, repository lint, and format checks pass.

The broader Desktop workspace-dependency build still encounters unchanged @maka/ui Astryx API type errors; the affected Runtime Host and Desktop main-process builds pass.