[Bug/Feature] Task list does not update while tasks are running — no mid-run push, subagent list is pull-only

[nevergow]

Environment

• dsh v0.1.0-rc.5 (developer preview, source build, master @ 47f9438)
• Web UI served over HTTPS via nginx reverse proxy; observed from mobile + desktop

Bug

The task list (session header background jobs + sidebar subagent list) freezes at the state it had when the first task was created while tasks are running. It only catches up after a task settles or after a page refresh. No real-time progress / status changes are visible during execution.

Root cause (from source)

1. session/jobs frames are only pushed on lifecycle events — never mid-run.

In packages/jobs/jobs-local/src/index.ts, notifyChanged(job.owner) is called only at:

• job creation (line 188)
• kill() (line 226)
• settle() — completion/failure (line 428)
• dispose/teardown (lines 474/495/524)

job.detail is only assigned in settle() (line 419); during running it stays undefined. There is no progress event and no periodic snapshot. The frontend JobListAction.tsx only refreshes from session/jobs frames (plus a local 1s clock for elapsed time), so the UI stays frozen at the creation-time state for the whole run.

2. Sidebar subagent list is pull-only.

In packages/client/runtime/src/client/sessions/manager.ts, refreshSubagents() is invoked only on session selection / subagent selection (lines 200, 218). There is no push frame for subagent status in api-proxy, so the list does not refresh while work is in progress.

Expected

• Live updates while a task is running: e.g. periodic session/jobs snapshots during long-running jobs, or a detail/progress update event from the jobs seam.
• Subagent list should refresh in near-real-time (push or poll while a parent session is active).

Impact

For long-running tasks (multi-minute bash / agent work), remote users (mobile) cannot see any progress; the UI appears stuck until the task settles or the page is reloaded.

[Sutera-Diffusus]

分析到位,jobs 只在生命周期事件推送、subagent 列表是拉取式,远端/移动端用户的进度感知就断了。官方补中推之前,OS 层可以兜一半:任务完成/待处理确认走系统弹窗 + 提示音 + 托盘角标,人不在页面、甚至页面冻结时也能被叫回来——我们 dsh-windows-notify 就是干这个的,也欢迎一起给「job progress 事件公开化」提诉求:https://github.com/Sutera-Diffusus/dsh-windows-notify

[weijiafu14]

你这份源码定位（jobs 只在四个生命周期点调 notifyChanged、job.detail 只在 settle() 里赋值、subagent 列表只在选中时 refreshSubagents()）正好是隔壁一个提案缺的东西——你在证明症状，那边在提通用的解法，两边互相不知道。

一、这是"没有 host → client 推送通道"的一个具体案例

#1289 提的是一条通用的 client/push 通道：API_REMOTE_FORWARDED_EVENTS 是一张 11 个名字的 as const 白名单，白名单之外的事件根本无法从 host 推到浏览器，所以插件只能轮询。

你这两条正是它的两个实例：jobs 有推送但只在生命周期点（运行中零帧），subagent 列表干脆没有推送帧。

我可以给一份第一手佐证：我维护 pi2dsh（Pi 生态兼容层），它在 DSH Web 里有自己的一半。因为拿不到推送，我们的代码里写着这个：

// 产品层的 MCP 管理页
const timer = window.setInterval(() => { void pull() }, 4000)

// 侧边会话面板（要跟一个正在跑的子会话）
const timer = window.setInterval(() => { void pull() }, 2000)

第二个 2000ms 就是你说的那件事——要看一个正在跑的子会话的进展，除了每 2 秒问一次没有别的办法。这两个数字没有任何依据，纯粹是"再快太费、再慢太钝"猜出来的。而且我们源码里还有一行注释："The panel polls; a cached answer would freeze the thread mid-turn"——拿不到"变了"这个信号，连缓存都不敢做。

建议两边互相引一下：你有源码级的症状证明，#1289 有通用解法，合起来比各自单独强。

二、一个措辞建议：别要"周期性快照"，要"变化事件"

你的期望里有这么一条：

e.g. periodic session/jobs snapshots during long-running jobs, or a detail/progress update event from the jobs seam

这两个是很不一样的东西，我建议把重点放在后者：

• 周期性快照 = 把轮询搬到服务端。 代价曲线不变——没事发生时也要付钱，长会话上尤其明显。而且周期一旦定死，快了费、慢了钝，和我上面那两个瞎猜的数字是同一个问题，只是换成由 DSH 来猜。
• 变化事件 = 有事才响。 而且 jobs 那边其实已经有现成的形状了：notifyChanged(job.owner) 已经存在，只是调用点只有四个生命周期时刻。你要的东西可以表述成一句非常小的话：

job.detail 在运行中更新时也应触发 notifyChanged，而不是只在 settle() 里赋一次值。

这么提的好处是它不需要新机制、不需要新帧类型、不需要定周期——只是让一个已经存在的通知机制覆盖它本来就该覆盖的状态变化。评审面前，"补一个漏掉的调用点"比"加一条周期性推送"好过太多。

（subagent 那半确实需要新东西——那边连帧都没有。所以你这帖其实是两个不同大小的诉求，值得在正文里明确区分：一个是补调用点，一个是新增推送面。）

三、@Sutera-Diffusus 那条兜底方向对，但注意它兜的是另一半

系统通知能在"人不在页面"时把人叫回来，这确实有用，而且和推送不冲突。但要说清楚它兜不到你这帖的核心场景：你描述的是「人正盯着页面，任务在跑，界面冻在创建时的状态」——用户在场。这种情况下 OS 通知不响（因为还没 settle），响了也没用（他已经在看了）。

两者是互补的：通知解决"我不在的时候别错过"，推送解决"我在看的时候能看到"。 建议在原帖里点一下这个区分，免得讨论滑向"装个通知插件就行了"。

边界与利益相关

我们不修 DSH 自家组件——jobs-local、api-proxy 的推送面、client runtime 的 refreshSubagents 都在 DSH 里。上面全是佐证和措辞建议。我没有读过 jobs-local 的源码，第二节关于 notifyChanged 的建议完全建立在你贴出的定位上；如果运行中触发通知有你我都没看到的代价（比如帧太密），以维护者判断为准。

利益相关：我维护 pi2dsh，是这条推送通道的直接受益者——它落地的当天，上面那两个 setInterval 就可以删掉。这一点先说在前面。这条不推销：你要的是 DSH 自己的任务列表能实时更新，装我们的东西对此毫无帮助（我们和你一样在轮询）。