[Bug] 后台服务停止响应后，页面永久显示“运行中”，且无法停止、发送消息或提交反馈

[beatcodexx]

你好，我在使用 DeepSeek Harness Developer Preview 时遇到了一个严重的卡死与恢复问题。

任务长时间运行后，后台服务似乎停止了响应，但原浏览器页面仍然把任务显示为“进行中”。同时，停止、发送消息和反馈功能均无法使用。

相关过程有录屏记录，但为了避免泄露账户、会话和项目内容，暂不公开上传原始录屏。如维护者确有需要，我可以另行提供经过脱敏处理的片段。

问题现象

任务运行较长时间后：

1. 任务长时间不再推进，但页面仍显示“进行中”。
2. Stop / 停止操作没有生效。
3. 输入框右侧按钮一直保持运行状态，没有恢复成发送按钮。
4. 无法发送新消息。
5. 无法发送 /feedback 命令。
6. Session log / Feedback 导出没有成功。
7. 无法要求 Agent 保存进度、生成 checkpoint 或总结当前状态。

最终形成以下状态：

任务不再推进
→ 无法停止
→ 无法发送消息
→ 无法使用 /feedback
→ 无法导出日志
→ 无法在退出前建立恢复点

新标签页无法访问，但旧页面仍显示“运行中”

任务卡住后，我在同一个浏览器中新开标签页，再次访问 Harness 的默认本地地址。

新标签页显示：

• 无法访问此网站
• 本地地址拒绝连接
• ERR_CONNECTION_REFUSED

检查时，Harness 的默认本地服务已经没有进程监听，系统进程中也没有发现仍在运行的 Harness/Node 服务。

但是，原来的 Harness 标签页仍保留完整界面，并继续显示：

• 会话仍为“进行中”
• 后台任务仍为运行状态
• Stop 操作无效
• 输入框无法发送消息

因此，现场状态表现为：

后台服务已经停止监听
→ 新标签页返回 ERR_CONNECTION_REFUSED
→ 旧页面没有显示连接已经断开
→ 旧页面继续显示任务“运行中”
→ 用户无法确认任务是否仍在工作，也不知道能否安全退出

我无法确认后台服务停止监听的具体原因，因此不对根因作判断。

恢复状态不透明

任务已经运行了较长时间，但界面没有说明哪些内容已经持久化，以及关闭或重新启动后可能丢失什么。

当时无法确认：

• 当前聊天内容是否已经保存
• 已完成的工具调用是否已经保存
• Agent 已修改的文件是否安全
• 当前任务是否存在 checkpoint
• 重启后能否恢复原会话
• 未闭合的 Running 状态会如何处理

期望行为

希望在后台服务断开、崩溃或停止监听时：

1. 旧页面明确显示“与 Harness 服务的连接已断开”，而不是永久显示 Running。
2. Stop / Cancel 给出明确的成功、失败或超时结果。
3. 输入框能够解除锁定，或提供独立于当前任务的反馈入口。
4. /feedback 和 Session log 导出不依赖当前会话继续正常运行。
5. 提供紧急恢复入口，例如：
   • 解除错误的前端 Running 状态
   • 保存或导出当前会话快照
   • 导出本地诊断日志
   • 显示最后成功持久化的时间
   • 重启后处理未闭合的 turn
6. 在关闭或重启前，明确说明哪些数据已经保存、哪些可能丢失。

运行环境

• 设备：Apple Silicon Mac
• CPU 架构：arm64
• 操作系统：macOS 15.7.1
• 系统 Build：24G231
• Harness npm 包：@deepseek-ai/dsh
• Harness 版本：0.1.0-rc.6
• Git commit：无法确认；npm 包未包含 gitHead
• 启动方式：npx @deepseek-ai/dsh web
• Node.js：v24.19.0
• npm：11.17.0
• 浏览器：Google Chrome 151.0.7922.109

隐私说明

为保护隐私，本报告没有公开：

• 本机用户名及个人目录
• 工作区名称和项目内容
• 会话名称、提示词及对话内容
• Session ID
• API Key、Token、Cookie 或账户信息
• 原始日志和未经脱敏的录屏

如维护者需要进一步诊断信息，请明确说明所需字段及脱敏要求。

[beatcodexx]

补充说明：通过 Codex 辅助恢复 Harness 会话

这次 Harness 会话在长时间运行后出现卡死，刷新页面后原来的界面消失，同一地址的新浏览器标签页也暂时无法访问。

后来我使用 Codex 作为辅助工具进行了本地恢复，过程大致如下：

• 先检查本机 Harness 服务状态，确认当时服务本身已经退出，页面显示的运行状态并不代表任务仍在后台执行。
• 检查 Harness 的本地持久化会话数据，确认之前的聊天内容和工具事件仍然保存，没有发现明显的会话日志损坏。
• 重新启动 Harness，并重新加载原来的浏览器标签页。
• Harness 冷启动后保留了之前已经保存的对话内容，并将未完成的回合标记为中断。未完成的工具调用没有被错误地假定为成功，而是保留为结果未知。
• 随后在原来的会话中发送继续指令，让 Agent 根据恢复后的对话内容和任务清单继续执行，而不是新建一个完全无关的会话。
• 最终，Agent 成功从保存的进度继续完成后续任务，并生成了新的测试结果和交付文件。

这次经历说明，即使持久化数据仍然存在，当前的前端运行状态、取消状态和会话恢复入口之间仍可能出现不一致。对用户来说，如果能提供一个明确的“从已保存进度继续”入口，或者在服务重启后自动显示可恢复会话，会比现在更安全、更容易理解。

出于隐私考虑，本次补充没有包含本机地址、文件路径、会话 ID、Cookie、密钥、原始日志或其他个人信息。

[xw901103]

我也遇到了

[beatcodexx]

再次补充：服务恢复后，任务状态仍可能停留在“进行中”

在上一条恢复说明之后，我又遇到了一次类似情况：

• Harness 本地页面可以正常打开，服务本身仍在运行；
• 当前会话最后一条回复实际上已经完成，也没有显示正在生成；
• 但任务面板仍然显示有任务“进行中”和若干“待处理”项；
• 刷新页面后，这个任务状态仍然没有收口；
• 页面没有提供明确的“已完成 / 已中断 / 可继续”状态说明。

进一步检查发现，发送按钮在输入框为空时处于禁用状态；输入文字后按钮可以恢复可用。因此这次更像是任务清单状态没有和实际会话状态同步，而不是服务仍在执行。

另外，经过长时间使用后，旧会话的上下文会变得非常大。此时即使本地服务正常，继续在同一个超长会话中请求也可能出现 API 请求或流式响应失败。当前比较可靠的临时办法是：刷新会话；如果旧会话过长，则在同一工作区新建会话，并用简短摘要接续工作。

希望 Harness 能进一步改进：

• 任务完成后自动清除“进行中 / 待处理”状态；
• 区分真实后台任务、已完成目标和历史任务清单；
• API 请求失败后明确显示失败原因，并解除不必要的输入锁定；
• 提供“从已保存进度继续”或“在同一工作区新建恢复会话”的入口。

本次补充没有包含本机地址、文件路径、会话 ID、用量信息、Cookie、API Key、原始日志或录屏。