{"version":"2.1.265","anchor":"interrupted-turn-tool-use-answers-now-also-suppressed-from-r","canonical_anchor":"resumed-sessions-now-synthesize-interrupted-tool-result-stub","heading":"Resumed sessions handle unresolved and interrupted tool calls via answeredToolUseIds","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/interrupted-turn-tool-use-answers-now-also-suppressed-from-r","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Resumed sessions handle unresolved and interrupted tool calls via answeredToolUseIds\n\nSession resume now tracks and fabricates results for tool calls left hanging by an interruption, via a new answeredToolUseIds field\n\n**What**\n\n- A new function synthesizes fabricated `tool_result` blocks (marked with `toolDenialKind: \"interrupted\"`) for tool_use calls that were left unresolved when a session was interrupted, tracked via a new `outTrailingUnresolvedToolUseIds` set. These are surfaced through a new `answeredToolUseIds` field returned from the resume-message-building pipeline and threaded through to the headless runner.\n\n- Session state serialization now carries this `answeredToolUseIds` field alongside the existing `supersededToolUseIds`\/`supersededToolNames` fields in several places.\n\n- When resuming after an interrupted turn, every id in `answeredToolUseIds` is now also added to the set of tool-use ids treated as already-answered, so they won't be re-prompted (previously only ids from the resumed-turn tool list and a currently-parked permission were included).\n\n**Why** Without this, resuming a session after an interruption could leave tool calls dangling with no result, or could re-prompt for permissions that were already effectively resolved. Tracking `answeredToolUseIds` end to end keeps resumed conversations consistent with what actually happened before the interruption.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}