Should a transient npx launch ever own a durable local Runtime Host?

[me2seeks]

Why

npx --yes maka-agent@next runs the exact package out of the npm cache, and that cache entry is not a durable deployment root. Today a transient npx invocation can launch a local Runtime Host that then outlives the invocation because of durable work (Goals, Scheduled Tasks). Once the cache entry is pruned, that Host has no owner: nothing can update it, and nothing is authorized to retire it. #3244 collects the evidence; this discussion is to pick the ownership model so implementation can start.

The question sits inside the #3231 retirement contract and the owner-scoped reconciliation being converged in #3709.

Options

	What happens when the npx invocation ends	Who owns durable work	Cost
A — invocation-owned	The Host it started retires with the invocation	Nobody — durable background work does not continue without a persistent owner	Small; matches what npx already means to users
B — managed local artifact	The Host lives on	A verified copy of the exact release in a Maka-owned persistent deployment becomes the installation owner; updates follow the #3231 retirement semantics	One explicit copy + verify step
C — connect-only	n/a — npx may connect to an existing compatible Host but never creates one	N/a	Smallest, but npx maka on a clean machine cannot run at all

Proposal: A for direct launch, B for explicit setup

The two user intents should not be forced into one global option:

• Direct npx maka → Option A. It may connect to an existing compatible Host or start an invocation-owned ephemeral Host, but a Host it starts retires when the invocation ends. Trying Maka out must never leave a dangling ownerless Host behind.
• Explicit npx ... runtime-host setup → Option B. The user deliberately asked for persistent hosting, so setup resolves and verifies the exact invoked release, copies it into a Maka-owned persistent deployment, and that deployment — not the npm cache path — becomes the installation owner.

Implementation notes

• The invocation-owned retire-on-exit path should reuse the owner-scoped reconciliation seam being converged in architecture(runtime-host): converge local Host lifecycle through owner-scoped reconciliation #3709 rather than growing a second local lifecycle path; the launch-owner guard findings from fix(desktop): quit retirement always times out before the Host can exit #4730 apply to npx-started ephemeral Hosts as well.
• feat(tui): add explicit local Runtime Host lifecycle and upgrade-conflict actions #3245 (TUI lifecycle actions) is blocked on this decision before an npx TUI may stop or replace a durable Host.

What I need

Maintainer confirmation of the A/B split (or a counterexample). If there are no objections in about a week, I will open the tracking issue and start with the Option A slice. Happy to take the first implementation slice either way.

简体中文

npx 的代码在 npm 缓存里，缓存会被清，不能当持久部署根。当前临时调用启动的 Host 可能因 durable 工作驻留，缓存一清就成了没人能更新、没人有权退休的无主 Host。建议按意图拆分：直接 npx maka = 调用级所有（调用结束 Host 必须退休，不留无主 Host）；显式 npx ... runtime-host setup = 托管构件（校验并拷贝精确版本到 Maka 持久目录，由它当安装主人，以后走 #3231 退休语义）。实现上复用 #3709 的 reconciler seam。请 maintainer 确认 A/B 拆分或给出反例；一周无反对意见我就开 tracking issue 并开始 A 切片。