Interrupted create_session still creates the session ~1.6 hours later, silently duplicating agent work

Summary

A create_session tool call was reported to the agent as interrupted (never completed), but the session was actually created and auto-started its kickoff prompt 1 hour 38 minutes later. The agent had correctly treated the call as failed and done the work itself in the meantime, so the late-arriving session became a duplicate worker on the same task, in its own worktree, editing the same files.

The damaging part is not the latency - it is that a side-effecting, non-idempotent tool reported failure and then succeeded anyway, long after the agent had reasonably compensated for the failure.

Evidence from the session event log

Every external_tool.requested in the session has a matching external_tool.completed - except the second create_session, which has no completion event at all:

18:01:18  external_tool.requested    create_session
18:01:44  external_tool.completed              <- 26s, normal
18:02:44  external_tool.requested    get_session
18:02:44  external_tool.completed
...
19:14:44  external_tool.requested    create_session
                                                <- no completion event, ever
21:04:41  external_tool.requested    send_session_message
21:04:41  external_tool.completed

The agent-side tool call surfaced as:

The execution of this tool, or a previous tool was interrupted.

Meanwhile, in the created session's own event log:

20:53:18  session.start           <- 1h38m after the 19:14:44 request
20:53:31  user.message            <- kickoff prompt delivered and executed

So the request at 19:14:44 did eventually take effect at 20:53:18, with no completion ever reported back to the caller.

Impact

1. Duplicated work. The agent, having been told the call was interrupted, performed the task itself. When the session finally materialised it began the identical task from the identical spec, producing two divergent branches for one issue. Cleaning that up required manually stopping the late session.
2. Wasted model spend. The duplicate ran autonomously in autopilot until it was noticed and stopped.
3. No way to detect it. There is no completion, no error, and no handle returned, so the caller has no id to poll and no signal that the request is still pending rather than dead. The only robust workaround an agent has is to poll an out-of-band source (worktree list / session list) after every interrupted side-effecting call - which is not discoverable.

Expected behaviour

Any of the following would resolve it, roughly in order of preference:

1. Cancel the side effect when the tool call is interrupted. If the result cannot be delivered, the session should not be created.
2. Return the handle even on interruption, so the caller can poll and either adopt or archive the session.
3. Make the request idempotent via a caller-supplied key, so a retry cannot create a second session and a late delivery can be reconciled.
4. At minimum, surface "still pending" distinctly from "failed", so an agent knows not to compensate.

Notes

• The first create_session in the same session completed normally in 26s, so this is intermittent rather than systemic.
• Both calls used mode: autopilot with a kickoff prompt, workspace_type: worktree.
• Client reported itself as github/autopilot.
• Timestamps above are UTC, from a single continuous session on 2026-08-30.

Start by tracing the create_session external_tool.requested and external_tool.completed lifecycle around interrupted calls, using the event log as reproduction evidence. Compare it with the first successful create_session and the send_session_message call. Done means an interrupted side-effecting request is cancelled, returns a usable handle, is idempotently reconciled, or is explicitly reported as pending instead of silently creating a session.