Fix background tool events lost and mispositioned in history

[drago-balto]

Summary

• Fix background tool events being lost when process() is cancelled mid-wait
• Fix background tool results appearing in wrong position in history (causing 'conversation cannot end with assistant message' error)

Issue 1: Events lost on cancellation

When _maybe_await_background_event() was cancelled (e.g., user spoke), the queue.get() task was left orphaned and could consume the next event from the queue, causing it to be lost.

Fix: Wrap asyncio.wait() in try/except to properly cancel the get_event_task on external cancellation.

Issue 2: Wrong history position

Background tool events were added to history with the triggering event_id (from when tool was called). When the tool yields much later after user spoke and a new process() started, events were placed in the OLD turns position, causing messages to end with assistant text instead of tool result.

Fix: Use current event_id at yield time (_append_local) instead of captured triggering event_id. This ensures background tool results appear at the END of history.

Test plan

• Added test test_background_tool_event_not_lost_on_cancellation
• All 265 existing tests pass
• Manual testing with an agent featuring long-running background tool
• [ ]
  Generated with Claude Code

---

Note

Medium Risk
Touches async cancellation and history ordering for background tools; mistakes here could drop tool results or corrupt message sequencing across turns.

Overview
Background tool loopback is made robust across turn cancellation. _maybe_await_background_event() now cancels/awaits its pending queue get() when externally cancelled so it can’t consume events intended for the next process() call.

Background tool yields are re-ordered to the current turn. _execute_backgroundable_tool() stops pinning tool events to the original triggering event_id and instead appends them with the current event context at yield time, preventing late tool results from being inserted mid-history.

Adds test_background_tool_event_not_lost_on_cancellation to cover the cancellation regression.

^{Written by Cursor Bugbot for commit da23844. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Completed event result silently discarded in cancellation handler

Medium Severity

In the CancelledError handler of _maybe_await_background_event, if get_event_task has already completed (consumed an event from the queue) before the cancellation takes effect, get_event_task.cancel() is a no-op and await get_event_task returns the event tuple — but the result is never captured or put back into _background_event_queue. The event is consumed from the queue and silently discarded. This race occurs when asyncio.wait()'s internal waiter is cancelled just after get_event_task completes but before asyncio.wait() can return. The completed result needs to be retrieved and re-enqueued via put_nowait so the next process() call can pick it up.