Claude Code’s cancellation controls do not guarantee remote work stops

Stopping a task in Claude Code is not a universal off switch for work running elsewhere. Superpower Daily’s review of five supplied documents finds that cancellation can end a client’s involvement without guaranteeing backend termination. Leaving a session creates another boundary: remote task execution, recovery and result availability each depend on separate rules.

Original analysis: We compared Anthropic’s Claude Code MCP reference, the MCP Tasks and cancellation specifications, Upstash’s toolkit documentation and its October 23 implementation walkthrough. The question was what cancellation, session exit and reconnection promise about server-side work. We separated client behavior, protocol requirements, execution and retention rather than treating them as one outcome. This was a document review, not an execution test. The requested evidence cutoff was October 24, 2026, at 20:31:03.550 UTC. The supplied snapshots were retrieved at 20:32:14.364 UTC, so they do not establish the documentation’s exact historical state at that cutoff.

Two ways to put a tool in the background

The Model Context Protocol, or MCP, connects Claude Code to external tools and data sources. But work appearing in the background can follow two different paths. An ordinary tool call can remain an open request while Claude continues working. A native MCP Task instead returns an identifier that the client uses to check progress and retrieve a result later.

For an ordinary backgrounded call, moving it out of the foreground does not replace the request with a server-managed task. The server still has to keep that request open. Stopping it cancels the call and suppresses its result in Claude Code, but does not guarantee the backend stops. Ordinary background calls also retain their call timeouts.

The cancellation specification explains how that request-level signal travels. With Streamable HTTP, closing the response stream signals cancellation, and the server must treat the disconnect accordingly. A local stdio connection, which communicates through a process’s input and output, uses a notifications/cancelled message instead. Servers should stop processing and free resources, but may ignore cancellation when a request cannot be cancelled or has already completed.

Native Tasks change the exchange. The server returns a task handle rather than waiting to deliver the final result. Before replying, it must durably create the task so a status request for that identifier resolves. That establishes a retrievable task record; it does not establish that every underlying execution survives every failure. After acceptance, native background tasks default to no Claude Code time limit. Waiting mode retains timeouts and requests cancellation on Esc or timeout.

Leaving the session is not cancelling the job

For native Tasks, the distinction is explicit: successful cancellation acknowledges the request, not confirmed shutdown. Claude Code stops following the task afterward. Cancelling while disconnected is narrower still: no cancellation request reaches the server, and Claude forgets the task. Esc alone does not stop background tasks; its cancellation behavior applies when Claude is waiting for a native task.

Session exit is a separate operation. No Claude Code exit option cancels a remote MCP task. A local stdio server does stop when Claude Code exits: the client signals its process, waits briefly and forces termination if necessary. That is a concrete shutdown mechanism for the local process, not evidence that work it delegated to another service also stopped.

Returning can restore the client’s view, but only under specified conditions. Interactive resumption of the originating session restores task following after connection when server settings are unchanged and the server still retains the state. A new session, a forked session or a one-shot -p resume does not provide that recovery. Resuming the conversation therefore depends on both the right session and surviving server-side information.

Upstash shows where persistence comes from

Upstash’s toolkit supplies a useful implementation comparison. Its default tasks live in the server process’s memory and disappear on restart. They exist only on the instance that accepted the call. On a serverless deployment, a later status request can reach an instance that never saw the task, while background work can be frozen or killed with the function.

Adding Redis and QStash changes both storage and delivery: task records become shared across instances, and QStash redelivers failed work into a fresh invocation. A retry starts the whole handler again. Upstash’s Workflow option instead preserves completed steps and retries the failed step. These are distinct recovery mechanisms, not consequences of merely labelling something a task.

There is positive evidence for recovery, not just caveats. In its October 23 walkthrough, Upstash says it killed its application during a running task, restarted it and saw QStash redeliver the task successfully to completion. That is an implementer-reported test, not an independent verification or a guarantee covering every failure. It demonstrates the specific recovery path the company described.

Cancellation also has implementation-specific effects. Upstash marks the task record cancelled and cancels a Workflow run; QStash redeliveries skip tasks already in a final state. Already-running handler code stops cooperatively, at points where it checks task.isCancelled(). Updating the record and preventing another delivery are therefore different from interrupting code that is currently executing.

Result retention adds a final clock. The Tasks specification permits expiry and deletion; a task’s lifetime may change or be unlimited. Upstash defaults to one day from creation, never extended. Expiry deletes its record and makes isCancelled() true, but running code must still observe that check. A missing record cannot establish whether external side effects occurred, just as recovering a session does not promise a result will remain available indefinitely.

The next evidence should cross the server boundary