On October 23, 2026, Anthropic announced MCP Tasks support in Claude Code. The product documentation describes a public beta requiring version 2.1.304 or later. A remote server can keep working after the client exits. Before enabling a tool that sends reports, changes permissions, or deploys code, decide how your team will stop that work and establish what already happened.
Consider a hypothetical report-delivery tool. It gathers data, prepares a document, and sends it to an approved destination. The operator closes Claude Code while the job is running. A later retry could send the report twice, or send an outdated version after access has changed. The server needs enough retained evidence to resolve that uncertainty.
The review below covers task ownership, approval expiry, and evidence needed before a retry. Its example record and recommended controls are illustrative; General Analysis has not run a live integration for this article.
Establish which execution path you are reviewing#
The MCP Tasks extension lets a server return a durable handle and expose progress through polling. Task support requires both sides to opt in. Record the client version, server identity, transport, and negotiated protocol before evaluating shutdown behavior.
Claude Code's eligibility rules require protocol revision 2026-07-28, enabled feature-flag fetching, and a main-conversation call on a supported surface. Terminal, eligible Agent SDK, and GitHub Actions sessions qualify; desktop, VS Code, and one-shot claude -p runs do not. Check the documented background settings for SDK or stream-json sessions.
Keep a plain backgrounded tool call separate from a server-owned MCP task in your inventory. A UI label that says work is in the background does not identify where its execution state lives. Ask the service owner which process or queue performs the action and which credential it uses.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Bind every task operation to its owner#
The extension's security requirements require authentication and authorization on each task request. Task identifiers must resist guessing; they may also act as bearer tokens. The current extension has no tasks/list method.
For a service shared across customers or teams, derive the task owner from authenticated server context when the job is created. Store the tenant, initiating identity, permitted resources, and operation alongside the task ID. Apply that scope to reads, input responses, and cancellation. A caller who knows another tenant's task ID should gain no access to its report or pending decisions.
Restrict raw task IDs in logs and support tickets, especially if the implementation uses them as credentials. Use an internal correlation ID for broadly visible dashboards, with restricted access to the actual task mapping.
Use your existing job store to identify authorized open jobs. Record task creation before dispatch and preserve its relationship to the underlying queue or service job. The protocol's lack of enumeration means an incident responder cannot depend on a generic list call to find everything a departing employee started.
These controls extend the MCP server security baseline into work that persists beyond the original request. They also need a policy for revocation: decide whether removing a user's access should stop their outstanding jobs, prevent result retrieval, or both. Enforce that decision at the service performing the work.
Separate a cancel acknowledgment from a stopped operation#
In Claude Code, reconnect through /mcp before stopping a disconnected task. Otherwise the client can forget it without sending cancellation. For a connected task, select it in /tasks and press x. Documented stop behavior.
The protocol cancellation contract is cooperative. Its acknowledgment does not guarantee that execution stopped, and the task may finish with another terminal status. Build your incident procedure around evidence from the worker and destination.
| Evidence available | Recommended operational decision |
|---|---|
| Client closed or stopped displaying the task | Locate the recorded server job; keep its outcome unresolved. |
| Cancellation request was sent or acknowledged | Check the worker and downstream operation before declaring containment. |
| Server reports cancellation, destination state is unknown | Reconcile any effects that could have occurred before cancellation. |
| Destination confirms the original operation completed | Retain its operation ID; assess cleanup without submitting the original action again. |
| Task record expired and no destination evidence remains | Escalate the uncertainty; do not automatically retry a consequential action. |
The table is a recommended acceptance policy. It deliberately asks for more evidence than the protocol requires a client to retain after cancellation.
For the report tool, separate document preparation from delivery. The delivery worker should check a server-owned cancellation flag and current authorization before sending. Coordinate that check with job claiming so another worker cannot bypass it with stale state. If a request has already reached the destination, reconcile the response or destination history; changing a local flag cannot retract it.
Keep the evidence after the task disappears#
The specification permits discarding expired task records. Set an application execution deadline separately from the task's retention lifetime, and retain the evidence needed to investigate uncertain effects.
The following example adds cancellation and effect fields to that job record for a report whose cancellation was acknowledged while its delivery remained unverified. These fields belong to your application, not to an MCP request. The identifiers and timestamps are synthetic.
Code source: illustrative
{
"operation_id": "report-delivery-example-42",
"owner": {
"tenant_id": "example-tenant",
"subject_id": "example-user"
},
"mcp": {
"server_id": "reports-service",
"task_id": "synthetic-task-placeholder"
},
"approved_destination": "example-review-space",
"execution_deadline": "2026-10-25T16:30:00Z",
"cancellation": {
"requested_at": "2026-10-25T16:05:00Z",
"acknowledged_at": "2026-10-25T16:05:01Z"
},
"last_task_status": "working",
"downstream": {
"operation_id": null,
"effect_status": "unknown"
},
"retry_decision": "hold_for_reconciliation"
}
Store the exact approved report revision or its digest with the operation, plus the reviewer and decision time. Keep sensitive report contents in an access-controlled artifact store rather than copying them into every log.
When the destination supports idempotency, use its documented mechanism and retain the resulting operation ID. Choose an application operation key that remains stable across recovery attempts; a newly created MCP task is not proof that the business action is new. Without a reliable destination lookup or deduplication mechanism, an unknown outcome needs an operator's decision.
Expire approval without losing the pending question#
Tasks can carry input requests. The elicitation specification requires credential collection through URL mode, outside the client; forms must not request passwords, access tokens, or payment credentials. A form accepting a proposed action still needs your service's authorization checks.
Bind each decision to the task, pending request, exact operation, and authenticated reviewer. Before delivery, check that the report revision, destination, and review authority still match. If any changed, require a fresh decision. Define an approval expiry independent of the task's storage lifetime, so a delayed response cannot authorize today's work using yesterday's access.
In non-interactive sessions, Claude Code requests cancellation when a task needs input, without invoking Elicitation hooks or the SDK's onElicitation callback. Task input behavior. Design unattended jobs with an explicit approval handoff or a safe stop; do not assume a hook will answer for an absent person.
For application-owned approval flows, the Managed Agents approval guide explains reviewer binding and uncertain delivery. Its API event names are specific to Managed Agents; use the MCP extension's input mechanism for an MCP server.
Decide when another attempt is safe#
Before approving the service, review a benign staging job through cancellation, loss of client contact, expired approval, and a missing task record. Use synthetic reports and a destination that cannot send real messages. Record expected and observed results separately.
An authorized operator should be able to find the job without the original terminal, prevent a queued delivery, and identify a delivery that beat cancellation. A changed destination should invalidate the old approval. Recovery must distinguish a missing response from an unperformed action.
Allow retries only when that evidence establishes what another attempt would do. Preserve unresolved outcomes in the incident record, with a named owner and the next lookup needed. A task disappearing from the client should never be the only evidence that consequential work has ended.
