Claude Code MCP Tasks for long-running jobs

Claude Code now runs long MCP tool calls as tasks. The server returns a handle and Claude keeps working. How it works, its limits, and where workers fit.

Claude Code can now run a long MCP tool call as a task: the server accepts the job and hands back a handle, Claude keeps working, and Claude Code follows the job until it ends. Anthropic announced MCP tasks on October 23, 2026, as a public beta in the Claude Code CLI that needs Claude Code v2.1.304 or later. They are built on the Tasks extension in MCP revision 2026-07-28, so a server has to support that extension before any of its calls can become one. This post covers what shipped, how a task moves from call to result, what survives closing the terminal, what a server author has to build, and where an AI worker fits beside it.

What	At launch
Status	Public beta in the Claude Code CLI
Version	Claude Code v2.1.304 or later
Protocol	MCP revision 2026-07-28, with the `io.modelcontextprotocol/tasks` extension
Servers	HTTP, stdio and claude.ai connector servers that support the extension
Where it works	Terminal CLI sessions, Agent SDK sessions and GitHub Actions runs
Where it does not	The VS Code extension, the desktop app, calls from subagents, one-shot `claude -p` runs, and sessions on a third-party provider such as Amazon Bedrock
Time limit	None by default, once the server has answered with the task

Why a tool call needed a handle

A normal tool call is synchronous. Claude asks, the server works, and the request stays open until the answer comes back. That suits a lookup and fails a build, a report export, a research run or a migration that takes minutes or hours: clients and the proxies between them give up long before such a job ends, and a dropped connection loses the result even when the work itself finished.

The MCP project's Tasks overview states the alternative plainly: tasks "let servers return a durable handle instead of blocking, so clients can poll for progress, provide input when needed, and retrieve the final result after reconnecting." The server decides, call by call, whether a request becomes a task. The client opts in once and handles whichever answer arrives.

Tasks first appeared as an experimental part of the protocol in the November 2025 revision. The 2026-07-28 release moved them out of the core and made them one of MCP's first official extensions, contributed by AWS, in the same revision that gave the protocol a stateless core and retired the old session handshake. AWS's Swami Sivasubramanian describes the extension as bringing "support for reliable, long-running agents." Claude Code's support follows from that revision: its newer MCP runtime, built on version 2.0 of the TypeScript SDK, is the one that speaks 2026-07-28.

How an MCP task works in Claude Code

From inside a session, a task runs like this:

Claude calls a tool on a server that supports tasks.
Instead of the result, the server answers with a task: an id, a status, timestamps and a suggested polling interval. Claude's tool call returns right there, and Claude carries on with the conversation.
The footer shows a count such as 1 MCP task, and /tasks lists the task with the latest status message the server sent.
Claude Code asks the server for the task's status with tasks/get once per polling interval. The server suggests the interval; Claude Code keeps it between 250 milliseconds and 30 seconds, and uses 2 seconds when the server names none.
When the job ends, the transcript records a line of the form MCP task <server task id> (<server>/<tool>) completed. and the result goes to Claude. It goes to Claude rather than into the transcript, so you ask Claude for it. If Claude is idle when the result lands, it starts on it unprompted.

The task answer itself is small. This is the example in Anthropic's documentation:

{
  "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
}

A task is always in one of five states, and the last three are final:

Status	What it means	What Claude Code does
`working`	The job is still running	Keeps polling
`input_required`	The server needs an answer or an approval	Collects it and sends it back with `tasks/update`
`completed`	The job finished	Gives Claude the result the call would have returned
`failed`	The job ended with an error	Tells Claude the error message
`cancelled`	The job stopped before it finished	Tells Claude the server's status message

To stop a task, select it in /tasks and press x, or ask Claude to. Claude Code then asks the server to cancel it. Cancellation in MCP is cooperative, so the server may still finish the job, and pressing Esc does not stop a background task at all.

What survives closing the terminal

This is the part that changes how a long job feels. A task on a remote server keeps running after you exit Claude Code, and no exit option cancels it. To collect the result, return to the same session with claude --resume, claude --continue or /resume. Once the server reconnects, Claude Code follows the task again, and Claude gets the result if the job finished in the meantime.

You do this	What happens to the task
Run `/clear` or `/branch`, or switch sessions, without exiting	The result still arrives in the conversation you are in
Exit Claude Code	A remote server's task keeps running; a stdio server's process stops with Claude Code
Resume the session the task started in	Claude Code follows it again once the server connects
Resume inside a one-shot `claude -p` run	That run does not follow the task
Start a new session, or use `--fork-session`	The new session does not follow it
Change the server's name or connection settings	The task is rejected on resume until the earlier settings are restored

Two cautions come with that. A stdio server is a local process, so its work stops when Claude Code exits unless the server's own documentation says the job lives somewhere durable. And when a server stops recognising a task id, Claude Code keeps asking for five minutes and then reports the outcome as unknown. Anthropic's advice for that case is the right advice for any agent: a second call may repeat the work, so have Claude use the server's other tools to find out what was already done before trying again.

Tasks versus automatic backgrounding

Claude Code has a second mechanism that is easy to confuse with tasks. Any MCP tool call in the main conversation that is still running after two minutes moves to the background on its own, so a slow server stops blocking the session. That works with any server, task support or not, but the job stays inside Claude Code: it is still one open request, and it ends when the session does.

	MCP task	Automatically backgrounded call
Who holds the job	The server, under a task id	Claude Code, as an open request
Needs server support	Yes, the Tasks extension on 2026-07-28	No
When it starts	When the server answers with a task	After two minutes of a plain call
Survives exiting Claude Code	Yes, on a remote server	No
Can be followed after a resume	Yes, in the same session	No

If you would rather Claude wait for results, two settings in the env block of settings.json do it. CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS set to 0 makes Claude wait for every MCP call to end. CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND set to 1 makes Claude wait for a task's result while still moving anything that passes two minutes into the background. Either way, the tool call time limits then apply for the whole task, where by default they stop applying once the server has answered with one.

When a task needs you

A task can pause in input_required, and that is where MCP's elicitation comes in. The server lists what it needs, Claude Code shows it as a dialog, and your answer goes back through tasks/update, so the job resumes without the original connection ever staying open. Declining, or pressing Esc, is an answer too, and the server decides whether the job goes on. The dialog stays hidden while /tasks is open, so close it to answer.

Elicitation comes in two shapes: a form for confirmations and plain structured input, and a link that opens in your browser for sign-ins. Secrets belong in the second, never in a form. In a non-interactive session there is nobody to ask, so Claude Code asks the server to cancel any task that requests input. A server therefore has to treat cancellation as a normal ending rather than an error.

What a server author has to build

Nothing changes for a server until it opts in, and the rules are strict about that. On a 2026-07-28 connection, every request from Claude Code carries its client capabilities in _meta, and a call that can become a task includes the Tasks extension there. Answer with a task when the extension is absent and Claude gets the tool error Unsupported result type 'task' for tools/call.

The checklist, from Anthropic's notes for server authors and the extension itself:

Advertise the extension in your server/discover capabilities.
Persist the task before you answer. The extension requires it, and Claude Code depends on it: after a resume it asks about the same id on a new connection.
Answer fast. On an HTTP or claude.ai connector server the task answer has to arrive within the per-request timer, so accept the job, answer, then do the work.
Send the required fields: taskId (at most 128 printable ASCII characters, no spaces), status, createdAt, lastUpdatedAt and ttlMs, which may be null.
Put the outcome in `tasks/get`. Claude Code does not use tasks/result, tasks/list or notifications/tasks. A completed response carries the normal tool result; a failed one carries an error object.
Handle `tasks/update` and `tasks/cancel`. Claude Code answers each input request once and ignores keys beyond 16 per task. It sends a cancel only while the server is connected, never on exit.
Make completion checks, retries and cancellation idempotent, because a reconnecting client will ask again.

That last point is the one to design for from the first line of code. A job that can be safely asked about twice is a job a client can recover.

Where WorkerKit fits

A task lets one session's long call survive. A worker is a job that never needed a session. WorkerKit workers run on a hosted runtime: on a schedule, when a signed webhook arrives, or when a person or an agent starts them. Every run leaves a run receipt with its result, its steps and its cost.

The WorkerKit MCP server does not answer with MCP tasks today, and a long job does not need it to, because its run tools were built on the same handle idea from the start. worker_run returns the run's receipt straight away while the run itself happens on the runtime, run_events follows it step by step, and run_get reads the result and the cost. No call sits anywhere near Claude Code's two-minute mark, and none depends on a protocol revision, so the same tools behave the same way in Claude Code, in Claude on the web and desktop, and in any other MCP client.

	MCP task in Claude Code	WorkerKit run
Started by	A tool call in Claude's main conversation	A tool call from any MCP client, the CLI, the API, a schedule or a webhook
The handle	The server's task id	The run id on the receipt
Followed with	`tasks/get`, polled by Claude Code	`run_events` for steps, `run_get` for the result and cost
Needs your input	Pauses in `input_required`, then resumes	Ends by asking; `run_answer` starts a linked follow-on run
Cancelled with	`tasks/cancel`, cooperative	`run_cancel`, cooperative; app actions already taken stay done
After you close the client	Continues on a remote server; resume the same session to collect it	Continues on the runtime; the receipt is readable from any client

The split that follows is simple. When the long job belongs to the coding session, such as a build started mid-refactor or an export you need before the next edit, it is a task. When the job repeats, it belongs to a worker, and Claude Code becomes one of the places you check on it.

Several standing jobs already exist as kits. Engineering Pulse writes a morning digest of pull requests needing review, stale branches, failing workflows and hot issues. Daily GitHub Repo Briefing reports what shipped, what is blocked and who needs a decision today. GitHub Issue Triage decides what each open issue is, how badly it hurts and whether it needs a maintainer. Weekly Ops Reporter compiles the weekly shipped, moving and blocked report. Competitor Site Pulse watches named competitor pages for product, pricing and messaging changes. Each runs at its own time whether or not a terminal is open.

Connecting Claude Code takes two commands, one for the public catalog and one for your fleet:

claude mcp add --transport http workerkit-directory https://mcp.workerkit.ai/directory
claude mcp add --transport http workerkit-workers https://mcp.workerkit.ai/workers --header "Authorization: Bearer pe_mgr_..."

The fleet key comes from Fleet access, and its scopes are named and opt-in, so a key carrying only readWorkers and readRuns lets Claude describe the fleet and follow runs without changing anything. The Claude setup guide walks through both mounts, including the sign-in route that needs no pasted key.

FAQ

What are MCP tasks in Claude Code?

An MCP task is a long job, such as a build or a report export, that an MCP server runs itself after answering Claude's tool call with a handle. Claude keeps working, Claude Code polls the server for the job's status, and the result reaches Claude when the job ends. Anthropic announced them on October 23, 2026, as a public beta in the Claude Code CLI.

Which version of Claude Code supports MCP tasks?

Claude Code v2.1.304 or later, in terminal CLI sessions, Agent SDK sessions and GitHub Actions runs. The server must support the MCP Tasks extension and connect on protocol revision 2026-07-28. Setting MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy rules tasks out.

Do MCP tasks work in the Claude desktop app or the VS Code extension?

Not at launch. Anthropic's documentation lists the VS Code extension and the desktop app among the surfaces without MCP tasks. Calls made by subagents and one-shot claude -p runs do not become tasks either.

Does an MCP task keep running after I close Claude Code?

On a remote server, yes. Exiting does not cancel it, and resuming the same session with claude --resume picks it up again, as long as the server's name and connection settings are unchanged. A stdio server runs as a local process, so its work normally stops when Claude Code exits.

How is an MCP task different from a background tool call?

A background call is a plain call that Claude Code moves out of the way after two minutes. It works with any server, but it ends when the session does. A task is held by the server under an id, so it outlives the session and can be followed again after a resume. Only servers that support the Tasks extension can create one.

Does the WorkerKit MCP server support MCP tasks?

Its tools do not answer with MCP tasks today, and long jobs do not need them. worker_run returns a run receipt at once, the run executes on WorkerKit's hosted runtime, and run_events and run_get follow it from any MCP client. Workers also run on schedules and webhooks with no client connected at all, and WorkerKit pricing lists what a run costs.

Sources: Connect Claude Code to tools via MCP (the MCP tasks and server-author sections), the MCP Tasks extension overview, the MCP 2026-07-28 release post, Anthropic's developer announcement on X and AlphaSignal's launch coverage. MCP tasks are a public beta, so their details can change.