Desktop conversation reads fail while the local Runtime Host stays unavailable after transport EOF

[Astro-Han]

English

What happened

On packaged Desktop, refreshing or opening a conversation surfaces:

• 刷新对话失败 / 对话内容暂时无法刷新，请稍后重试。
• 读取对话失败 / 对话内容暂时无法读取，请稍后重试。

The conversation store is not the failing path. Desktop's main process is still up. The local Runtime Host transport read side has already ended (read_eof), so sessions:readMessages, sessions:listActiveInteractions, and MCP client.capability.replace all fail with:

RuntimeHostRequestInterruptedError
 operation: subscription.open | client.capability.replace
 dispatch: not_dispatched
 reason: connection_lost
 retryable: false
 cause: RuntimeHostTransportError code=read_eof
 "Runtime Host transport read side ended"

The copied diagnostic then says Diagnostics unavailable: Runtime Host is unavailable. There is no Host exit code, signal, crash stack, or Host-side log in the report, so the user-visible toast is a downstream read failure on a dead Host pipe.

This is not a one-shot blip. The same read_eof repeats every few seconds for minutes while the Electron main process stays alive (uptime ~6h in the captured reports).

Not claimed: why the Host process exited. The current report cannot distinguish crash, kill, or an immediate close after a failed reconnect.

Not #3280. #3280 recovers conversation reads after the Host comes back. It does not explain or recover a Host that stays unavailable, and it does not put Host exit evidence into the diagnostic the user actually copies.

Not #3234. #3234 is about reconciling a dispatched control mutation. These failures are not_dispatched reads/subscriptions on a lost pipe.

How to reproduce

No stable from-scratch reproduction yet. Observed on a long-lived packaged Desktop session:

1. Leave Maka Desktop running for several hours on Windows.
2. Open or refresh a conversation after the local Runtime Host pipe has already ended.
3. Copy the toast diagnostic.

Expected: either the Host recovers, or the diagnostic names the Host exit (code/signal/crash) instead of only downstream connection_lost read failures.

Actual: conversation toasts repeat; main-process logs show the same read_eof every few seconds; Runtime Host diagnostics are unavailable.

Environment

• Maka: 0.1.10 (packaged)
• OS: Windows 10.0.26200 (x64)
• Surface: Desktop
• Electron 43.2.0 · Chrome 150.0.7871.129 · Node 24.18.0
• Locale: zh-CN
• Main process uptime at capture: 21683s and 21834s
• Captured at: 2026-08-20T08:26:15Z and 2026-08-20T08:28:46Z

Logs, screenshots, or additional context

Two Desktop diagnostic reports from the same session, ~2.5 minutes apart. Both end with:

Runtime Host
Diagnostics unavailable: Runtime Host is unavailable

Recent main-process errors in both reports are only:

• Error occurred in handler for 'sessions:readMessages'
• [runtime-host] MCP capability alignment failed
• later also sessions:listActiveInteractions

Related work that does not close this:

• #3280 — recover reads after reconnect (open)
• #2901, #2608 — same-target reconnect state / capability lease (merged)

Suggested next evidence, not a proposed patch:

1. Host child exit code, signal, and stderr must land in main-process logs and the copied diagnostic.
2. While the Host stays unavailable, do not present each sessions:readMessages retry as an independent conversation-read toast.
3. Decide whether a Host-stability fix is warranted only after that exit evidence exists.

简体中文

发生了什么

打包版 Desktop 刷新或打开对话时出现：

• 刷新对话失败 / 对话内容暂时无法刷新，请稍后重试。
• 读取对话失败 / 对话内容暂时无法读取，请稍后重试。

失败路径不是会话存储。Desktop 主进程仍在运行。本地 Runtime Host 的 transport 读端已经结束（read_eof），因此 sessions:readMessages、sessions:listActiveInteractions 和 MCP client.capability.replace 都以同一错误失败：connection_lost / not_dispatched / retryable: false，cause 为 RuntimeHostTransportError code=read_eof。

复制出的诊断末尾是 Diagnostics unavailable: Runtime Host is unavailable。报告里没有 Host 退出码、信号、崩溃栈或 Host 侧日志。用户看到的 toast 只是死管道上的下游读失败。

这不是一次抖动。同一条 read_eof 会在几分钟内每隔几秒重复，而 Electron 主进程仍然活着（捕获时 uptime 约 6 小时）。

不主张： Host 进程为什么退出。现有报告无法区分崩溃、被杀，还是重连失败后立刻断开。

不是 #3280。 #3280 修的是 Host 回来之后如何把对话读取接上。它不能解释或恢复持续不可用的 Host，也不会把 Host 退出证据写进用户实际复制的诊断里。

不是 #3234。 #3234 针对的是已经 dispatch 的 control mutation。这次是丢失管道上尚未发出的读/订阅。

如何复现

还没有从零开始的稳定复现。出现在长时间运行的打包 Desktop 会话中：

1. 在 Windows 上让 Maka Desktop 连续运行数小时。
2. 本地 Runtime Host 管道已经结束后，打开或刷新对话。
3. 复制 toast 诊断。

期望：Host 恢复；或者诊断写明 Host 退出原因（code/signal/crash），而不是只有下游 connection_lost 读失败。

实际：对话 toast 反复出现；主进程日志每隔几秒重复同一条 read_eof；Runtime Host 诊断不可用。

环境

同上英文区。

日志与上下文

同一次会话、间隔约 2.5 分钟的两份 Desktop 诊断。建议的下一步是补齐 Host 退出证据，而不是先猜补丁：把子进程退出码/信号/stderr 写进主进程日志和诊断；Host 持续不可用时不要把每次 sessions:readMessages 打成独立的读对话 toast；有了退出证据后再决定要不要修 Host 稳定性。

[HuYellow]

I'm taking this. I'll preserve bounded, redacted exit evidence for a locally spawned Runtime Host (PID, exit code/signal, and stderr tail), associate it only with the process selected by the connection, and surface it through the Desktop main-process diagnostic log with regression coverage.

OpenAI Codex is assisting with implementation and tests; I will review the final diff and accept responsibility for the contribution.

[M4n5ter]

@HuYellow Linking this from #3463: the bounded local Runtime Host exit evidence described here already owns the demonstrated Host-side diagnostics gap, so I did not open a duplicate issue.

The clean boundary is the locally spawned Host selected by the Desktop connection: preserve its PID, exit code/signal, and bounded redacted stderr tail after that Host exits. Managed-service logs should remain owned by the service backend, and remote Host logs by the operator; this follow-up does not need a generalized cross-deployment persistence layer.