Copilot CLI 1.0.97 resume reports interrupted calls: Sume retries

Copilot CLI 1.0.97-0 reports interrupted tool calls on resume and avoids replaying canceled writes. Reuse the same idempotency_key for an interrupted Sume call.

5 min readSume
All posts

If a Copilot CLI session is suspended in the middle of a Sume tool call, 1.0.97-0 now tells you on resume. The release notes say "Resuming suspended sessions now reports interrupted tool calls and avoids replaying canceled writes." For Sume, the safe next step is to look up the job before you ask the agent to submit again, and to reuse the same idempotency_key if you do.

This applies to any write or paid call over Sume's hosted MCP server at https://mcp.sume.com/mcp.

What does Copilot CLI 1.0.97-0 change on resume?

Two things in one line of the release. Interrupted tool calls are reported when a suspended session resumes, and canceled writes are not replayed. A related fix says cached MCP tool calls recheck their definition when a concurrent tool-list refresh changes the catalog.

The release does not say a call that already reached the server is undone. The server may have accepted it before the session was suspended.

Resume behavior in Copilot CLI per the 1.0.97-0 release notes (read 2026-10-13)
SituationReported behavior
Suspended session resumes with an interrupted tool callReported to you
A write that was canceledNot replayed
Cached MCP tool call, tool list refreshed meanwhileDefinition rechecked

What happens to a Sume call that was in flight?

Per the tools and gates page, every write and paid call needs an idempotency_key for deduplication. That is the property that makes a retry safe: the same key with the same request should not create a second paid job, while a new key is a new request.

So after a resume that reports an interrupted generate_video call, do not let the agent invent a fresh key and resubmit. Either find the job first or resubmit with the key from the interrupted attempt.

How do I check whether the job exists?

Jobs are readable through the read tools. Ask the agent to list recent jobs and read the status of the one that matches your prompt before doing anything else. Read tools are available to an OAuth token that holds only mcp:read, so this check works even in a read-only session.

If the job exists, wait on it instead of resubmitting. If it does not, a fresh submit is correct.

  • Store the idempotency_key in your task notes or session summary before the call, not after.
  • Use dry_run=true if you want the cost again before a resubmit.
  • Send max_spend_credits on the retry too; Sume enforces it only when the request includes it.

Does the Copilot fix replace idempotency keys?

No. Copilot's change is about what the client replays and what it tells you. It cannot see whether a remote server already accepted a request. The key is the server-side guarantee, and the two work together: the client stops replaying canceled writes, and the key covers the call that did go out.

Check what your credential can see with mcp_health and tools_list after you resume, since a re-authenticated session may carry a different scope than the one you started with.

What should I tell the agent after a resume?

Give it a short rule in your project instructions: after a resume that reports an interrupted Sume call, read the job list first, never mint a new idempotency_key for the same request, and stop and ask if the job state is unclear. This keeps a suspended laptop or a dropped connection from turning into a second paid render.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume