Bug: Archived active conversation keeps running with no visible status

[yzke]

Summary

Archiving a conversation while its current turn is still running hides it from the active list, but the underlying turn continues without a visible running state. It is then unclear whether the task is still consuming resources, whether the final transcript will be preserved, or whether Archive is expected to stop the turn.

Reproduction

1. Open a new conversation in the web UI.
2. Send: 你好帮我完成一个我的世界.
3. Click Continue, then click Archive while the turn is still running.
4. Observe the archived conversation and its backing session log.

Observed behavior

In a local reproduction, the archived session log continued growing after the Archive action:

• 10:54:45: 255,318 bytes
• 10:54:55: 266,285 bytes
• Later 6-second sample: 418,672 → 425,434 bytes

The newest events were still reasoning-chunks; there was no new terminal finish/stop event. The generated conversation title was 帮我完成我的世界任务.

This confirms that the turn continued after the conversation was archived, but the UI did not expose that state.

Expected behavior

Any of these would make the lifecycle safe and understandable:

• Keep the task running after Archive, but show an explicit still running / archiving state in the archived view and preserve the eventual transcript.
• Defer or block Archive until the active turn finishes, with a clear explanation.
• Treat Archive as stop-and-archive, and emit an explicit terminal event.

Please document the intended semantics of archiving an active conversation and make the running/final state visible.

补充

我的操作顺序是先点“继续”，再点 Archive。我不认为 Archive 必须自动等同于 Stop；允许任务继续运行可以接受。问题是归档后会话直接从正常入口消失，我无法再查看它是否还在运行、做了什么，或者如何停止。

这次会话的后续记录如下：

• 大约在 02:51:48 归档，当时 turn 1 仍在运行。
• 同一个 turn 一直运行到 03:16:10 才以 interrupted 结束，即归档后又继续约 24 分钟。
• 这段时间执行了 68 次工具调用，包括 27 次 Bash、21 次 edit 和 7 次 write。
• 其中启动了两个后台 Bash 下载任务；它们完成后，通知被写入该会话的 next-step inbox。
• 项目目录最后约 565 MB，其中约 560 MB 是任务下载的便携 Node/Chrome 工具。这些是正常的构建和测试依赖，并未发现异常下载目标。

这次只能确认：Archive 没有中止当时正在运行的任务。日志后续还有两个 turn，但触发来源无法确定，因此不把它们当作自动唤醒的证据。会话最终正常完成，inbox 为空，也没有发现相关进程遗留。

另外，Stop 也不一定让整个会话完全安静：当前 session.cancel 会保留 inbox；通过 run_in_background 启动的 Job 由 Job 服务独立管理，不会自动执行 job_kill，完成后还可能向会话投递通知。因此，如果还有后台 Job 或排队消息，“先 Stop，再 Archive”仍可能不够。

结合已有的归档恢复反馈 #40、#1147、#1587，以及后台任务控制建议 #757，我觉得比较直接的改进可以是：

1. Archive 活动会话时明确提示“任务仍会继续运行”。
2. 提供已归档会话入口和 Unarchive；如果归档会话仍在运行，保留状态、后台 Job 和 Stop 控件。
3. 如果提供 “Stop and archive”，需要说明它是否只停止当前 turn，还是也处理 inbox 和该会话拥有的后台 Job。

这次复现没有发现权限绕过、异常外联或永久孤儿进程。这里确认的是一个可见性和控制问题：会话仍在按已有权限正常工作，但用户归档后缺少入口了解它是否还在运行、做了什么，以及如何停止。

[denial123789]

这个复现与当前源码语义一致，也准确指出了一个 UI 可见性缺口。

当前 archiveSession 只修改 workspace registry 的 archived-session 集合：API 路径调用 ctx.workspaceRegistry.archiveSession(sessionId) 后返回新的归档集合，并没有调用 session.cancel 或 Agent 的停止逻辑：api-proxy.ts:2905-2919。Host 文档也明确写着，Archive 只从 grouping surfaces 隐藏 Session，不触碰日志或 workspace accounting：apiproxy/README.md。因此你测到日志继续增长，不是偶发现象，而是当前实现的直接结果。

客户端侧的已知限制更关键：归档后的 Session 会从 workspace、Ungrouped、搜索和平铺列表全部消失；当前也没有 archived-session 查看或 unarchive 控件：ui-workspace/README.md / Known limitations。所以“后台继续运行但操作者失去状态入口”确实是当前 UX 的危险组合。

现阶段安全操作顺序建议是：

1. 如果目的是停止消耗，先对活动会话执行 Cancel/Stop，不要把 Archive 当作停止操作。
2. 等待 session-status(running:false) / 对应终止事件落地并确认输出停止增长。
3. 再执行 Archive。

session.cancel 的当前契约是只中止活动 turn，并保留排队的 inbox 工作；如果队列里还有 waking message，它之后仍可能被 AgentLoop 取出，因此还要先检查/清理队列：apiproxy/README.md。

产品侧建议把语义拆清楚：

• Archive 活动会话时显示阻断确认，明确说明任务会继续；或提供 “Stop and archive”。
• 归档视图保留 running/waiting 状态、Cancel 和 Unarchive。
• Archive 菜单不应只依赖“非破坏性”判断；对活动 turn 来说它有明显的可观测性影响。

你的日志大小采样已经是很好的证据。若再附上 archive 前后的 session-status、最后一个 terminal event，以及 inbox queue 是否为空，就能把“当前设计语义”和“是否还有队列任务继续唤醒”完全区分开。