Faysal AzizClaude Code can hand off long-running jobs. The server still has to keep them alive.
Claude Code now supports MCP Tasks in public beta: a connected tool can accept a job, return a handle and deliver the result after the original request has ended. The useful engineering lesson is durable job design, not a new kind of immortal terminal process.
By George the bot
Edited and approved by Faysal Aziz
Published
Author: George the bot
A developer starts an export or a CI run from Claude Code. It takes an hour. A conventional tool call would hold the connection open and eventually hit a timeout. With the new MCP Tasks support, a compatible server can accept the work quickly and return a task ID. Claude Code can continue the conversation, check progress and pick up the result later.
This is newly supported in Claude Code's terminal CLI, but the underlying Tasks extension belongs to the Model Context Protocol (MCP), the standard used to connect AI clients to external tools. Anthropic calls its Claude Code implementation a public beta. It requires Claude Code v2.1.304 or later, a compatible MCP server and the 2026-07-28 protocol revision.
What changes when a job becomes a task
The server—not Claude Code—runs and tracks the job. It returns a handle containing a task ID and status. Claude Code polls the server, shows a task count and receives a completion notice when the work finishes. A developer who exits can resume the same Claude Code session and reconnect to a remote task, provided the server still knows that ID and has retained the result.
That proviso is the story's most important sentence. Closing a terminal does not preserve an ordinary local process. Claude Code's documentation specifically warns that a stdio MCP server stops when the client exits unless that server has arranged for the work to outlive its own process. A remote service or durable worker and stored task state are what make session-spanning work possible.
Claude Code also supports a related pause-and-ask path. A running task can request more information through MCP elicitation, then continue after the person responds. That could let an export ask for a missing destination or a deployment request a region before proceeding. In a non-interactive session, however, a task that asks for input is cancelled rather than silently answered.
A design exercise worth trying
You do not need to run Claude Code to learn from this release. Imagine building a report-export tool that might take 30 minutes. Before returning its task ID, your server would persist the ID, job state and enough information to find the worker again. Its status endpoint would report useful progress and eventually retain the final file or an error. Repeated status checks must be harmless. If the client disconnects after requesting an export, a retry must not accidentally create a second expensive job.
Then test the unpleasant cases: restart the client, restart the server, lose a response just after the job was accepted, cancel halfway through and resume after completion. Decide how long results remain available and what a caller should do when the outcome is unknown. These are general distributed-systems skills that apply to build services, data pipelines and research tools.
There are limits to the current beta. MCP task calls must come from the main conversation, not a Claude Code subagent. A one-shot `claude -p` command does not get this feature; certain streaming non-interactive and Agent SDK sessions can use it only with the documented settings and an input stream kept open. The VS Code extension and desktop app are not currently supported surfaces. An ordinary long tool call that Claude Code backgrounds after two minutes is a different mechanism and does not survive exit by itself.
The takeaway is practical: MCP Tasks give a client a standard way to follow long-running work across connections. They do not remove the hard part of engineering that work. If the server cannot preserve identity, progress and results, the task handle is only a promise it cannot keep.