Stop an unanswered request for the wheel outliving its run

[davidmckayv]

The cross-conversation half of #140.

What it looked like

A brand new channel, on a completely unrelated question, showing:

The assistant needs you. Google Docs is asking for sign-in before I can read the PRD document. [Take control]

with a live button. The request came from a different conversation, minutes earlier, about a document that thread had never mentioned. The audit trail agreed it was still outstanding:

02:54:29  computer.help_requested
01:57:36  computer.control_released
01:56:43  computer.control_taken

A help_requested with nothing after it.

Why

Control is a property of the Bot's computer, not of the conversation that asked. So an unanswered request sits on the computer and is shown to anybody looking at that Bot's screen, in any channel, indefinitely. The run that made it ended long before.

The part to care about is not the stale button. It is the reason: written for the person who asked, and rendered to whoever looks. In a deployment with more than one person that is somebody else's context on your screen — here, the existence and subject of a document.

The change

An unanswered ask stops being shown after ten minutes, and its reason is dropped with it, because the reason is the part that leaked.

Expired on read, not on a timer. There is nothing to wake: the asking run is over, and the only thing that cares is whoever looks next. A timer would be a scheduler for a value nobody is waiting on.

A person holding the wheel is never timed out. They may be halfway through typing a code, and taking the browser back mid-sign-in is worse than any stale prompt. Only the ask expires, never the holding, and there is a test pinning that.

Ten minutes is long enough that somebody who stepped away can still act on it, and short enough that it does not follow the Bot into tomorrow. The run does not resume either way, so the value trades "still useful" against "still on screen" and nothing else.

Tests

Three, on the state machine with an injected clock — the module has no Playwright import, so this needs no browser:

• inside the window, the request and its reason are still shown
• past it, requested is false and the reason is gone
• a person who took the wheel still holds it an hour later

	result
bun run test	1156 pass, 8 skip, 0 fail, 1164 across 103 files
bun run typecheck	clean, all four packages plus agent-computer
bun run format:check	clean

What this does not fix

The other half of #140, and the worse one for the person it happens to: an unanswered handover leaves a tool_calls message with no matching result, so the asking thread is permanently unusable —

400 An assistant message with 'tool_calls' must be followed by tool messages responding to
each 'tool_call_id'.

Every later message in that conversation fails, and the only way out is New chat, which loses it. That needs the run to write a result when it ends without one — "the person did not take the wheel" is an outcome the model can act on, and it keeps the history valid. Separate change; #140 stays open for it.

These are worth separating because they fail differently. This one shows one person's context to another. That one destroys a conversation.