Anthropic Lets Claude Code Run Hours-Long Jobs Without Dropping Them

Anthropic has added two Model Context Protocol capabilities to Claude Code: Tasks for long-running server jobs and Elicitations for requesting human input during a tool call. MCP is the protocol Claude and other AI clients use to connect with external tools and data sources. Both capabilities are available in the Claude Code CLI, with Tasks in public beta, and Anthropic says broader Claude support will follow.

A synchronous MCP tool call usually has 30 to 60 seconds to finish. That window works for a database lookup, but CI pipelines, research runs, batch exports, and training jobs can take minutes or hours. Some operations also need approval or missing information after work has begun. Tasks preserve long-running job state across connections, while Elicitations provide a standard path for collecting input.

Long jobs outgrow tools/call

A conventional MCP tools/call request blocks until the server returns its result or the client times out. Tasks let the server return a durable handle quickly, allowing the client to poll for progress, provide input, and retrieve the result later. A remote job can continue after Claude Code exits, provided the server persists its state.

The extension was formalized in the MCP 2026-07-28 specification as one of the protocol’s first official extensions. AWS contributed the work to support durable agents on infrastructure that does not depend on persistent client connections. Anthropic describes the implementation in its MCP announcement.

The task lifecycle in Claude Code

Claude Code follows a task from the initial tool call through completion using a short sequence:

1. Claude calls a tool on a server that supports Tasks.
2. The server returns a task handle with an identifier, status, timestamps, and polling interval.
3. Claude Code continues other work while the footer displays a counter such as 1 MCP task.
4. The client sends tasks/get requests until the job completes, fails, requests input, or is cancelled.
5. Claude Code adds a completion entry to the transcript and gives the result to Claude on the next turn.

A resumed session can reconnect to an existing remote task with claude --resume. The server must recognize the same task ID on the new connection, so task metadata and results need durable storage before the initial response is sent.

Current compatibility

Support depends on the Claude surface, protocol revision, and calling context:

Eligible servers must use HTTP, stdio, or a claude.ai connector and negotiate revision 2026-07-28. Setting MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy disables the required protocol path.

The normal per-server and idle timeouts remain active until the server accepts the job and returns a task handle. After acceptance, Claude Code applies no wall-clock limit to the background task by default.

The wire contract

A server starts task-based execution by returning a task object from tools/call. The minimum response has this shape:

{
  "resultType": "task",
  "taskId": "build-7f3a9c2e",
  "status": "working",
  "statusMessage": "Compiling, 40 of 212 files done",
  "createdAt": "2026-10-22T14:03:07Z",
  "lastUpdatedAt": "2026-10-22T14:03:07Z",
  "ttlMs": null,
  "pollIntervalMs": 5000
}

Claude Code sends tasks/get according to pollIntervalMs, clamped to a range of 250 milliseconds through 30 seconds. Subsequent responses use resultType: "complete" and report one of five states:

• working: The server is still processing the job.
• input_required: The server has paused for information or approval.
• completed: The final result is available.
• failed: Processing ended with an error.
• cancelled: The task stopped before completion.

Task IDs must remain valid across connections because a resumed Claude Code session polls through a new connection. Servers should also make completion and cancellation operations idempotent, since a network failure can leave the client uncertain about whether an operation succeeded.

Human input, mid-run

Elicitations let an MCP server request information while a tool call or task is active. A refund service can ask for confirmation, for example, while a deployment tool can request a missing region. Claude Code displays the request, collects the response, and returns it to the server without additional client configuration.

Claude Code supports two elicitation modes with different purposes:

Form elicitations should not collect passwords, access tokens, or other secrets. Authentication flows belong in URL mode, where the browser and external service handle sensitive data outside the terminal dialog.

Claude Code passes a URL-mode link as a command-line argument to the operating system’s URL handler. The escaped argument has a length limit, and URLs dominated by percent-encoded characters can reach it at roughly 4,000 characters. Claude Code can only decline the request after that limit is exceeded. An Elicitation hook can validate requests or provide automated responses when an interactive dialog is unsuitable.

A running Task can enter input_required and include an inputRequests map. Claude Code collects the requested values and sends them through tasks/update, allowing the server to resume the same job without holding the original connection open.

Where the pair fits

Tasks and Elicitations move durable execution and human input into the protocol, replacing application-specific polling loops and approval webhooks in several common workflows:

• Research agents can coordinate many fetch and synthesis steps without generating artificial output to keep a request alive.
• CI and build servers can return a handle immediately while Claude continues editing code.
• Data pipelines and migrations can pause before destructive operations and request approval.
• Payment and refund services can collect explicit confirmation before executing a transaction.
• Session-spanning jobs can continue remotely and reconnect when the user resumes Claude Code.

Failure modes to design for

Public-beta support carries several operational constraints that server authors and automation owners need to handle:

• Connection settings must remain stable. Renaming a server or changing its transport during a task causes Claude Code to reject it on resume with reconfigured to a different transport.
• Plain one-shot runs cannot create MCP tasks. Non-interactive automation should use the Agent SDK or --input-format stream-json with CLAUDE_AUTO_BACKGROUND_TASKS=1.
• Reconnect failures can produce an uncertain outcome. If the server rejects a task ID after reconnection, Claude Code polls for up to five minutes before reporting outcome unknown. Blind retries can duplicate work that already completed.
• Non-interactive elicitations cancel the task. Servers must handle cancellation cleanly when no user is available to answer.
• Local processes need their own durability plan. A stdio server terminated with the client cannot keep computing unless the work has been delegated to a durable worker.

A server-side checklist

An MCP server adopting these features should cover the following implementation details:

• Negotiate protocol revision 2026-07-28 and advertise the required capabilities.
• Persist each task ID, status, timestamps, input requests, and final result before responding.
• Honor the requested polling cadence and return clear status messages.
• Make retries, completion checks, and cancellation idempotent.
• Support input_required and validate all elicitation responses.
• Test reconnects, client exits, transport changes, timeouts, and non-interactive cancellation.

Anthropic’s Claude Code docs define the fields expected in tasks/get responses. The Tasks extension spec covers the protocol lifecycle and capability negotiation.