Claude Code MCP Tasks are in public beta: what survives closing the terminal

Claude Code now supports public-beta MCP Tasks, allowing a supporting server to accept a long job and return control while the job runs. A remote server task can continue after you close Claude Code, but a local stdio server's process normally stops on exit: those are different durability guarantees.

Anthropic's ClaudeDevs announcement announced Tasks and Elicitations for the CLI during the October rollout. This article checks the current MCP documentation on 31 October 2026, rather than assuming the announcement means every Claude app or MCP server supports them.

What changed for people running agents on their plan?

Previously, a slow tool often looked like one long wait from the user's perspective. A task-capable server can instead accept a job, return a task handle and let Claude Code follow its status. When the task finishes, Claude receives the result. That is useful for report exports or builds where the server does the long-running work.

The important distinction is where the work lives. Ordinary backgrounding frees the conversation while a client-side tool call continues. MCP Tasks give the server responsibility for a tracked job. Neither mechanism means the requested output is already finished.

Work type	Where to check it	What closing Claude Code means
Ordinary background tool call	Claude Code task view and transcript	Do not assume server-task durability
MCP task on a remote server	/tasks, plus server status	Server task keeps running; resume the original session to follow it
MCP task through a local stdio server	/tasks and that server's own documentation	The local server process stops; survival needs a separate server guarantee
Task waiting for human input	Elicitation dialog	Resolve or stop it deliberately; do not treat waiting as completion

This is a workflow feature, not a new subscription entitlement. For account compatibility, start with which Claude subscription integrations are allowed.

Which sessions actually get MCP Tasks?

The current Anthropic reference documents public-beta support from v2.1.304. Its changelog dates that version to 19 October; the public announcement and feature rollout are separate from the version's release date.

Check all of these before debugging a server:

• The server implements tasks and connects through a supported HTTP, stdio or claude.ai connector connection using protocol revision 2026-07-28.
• The session can fetch the relevant feature flags and is enabled for the feature. Third-party-provider sessions and disabled flag fetching are exclusions in the current documentation.
• The call comes from the main conversation, not a subagent.
• The surface supports tasks. Anthropic currently names terminal CLI, eligible Agent SDK sessions and GitHub Actions, but excludes the VS Code extension and desktop app.
• Interactive sessions are the simplest case. Eligible SDK or stream-JSON runs have additional background-task settings and must keep input open. A one-shot claude -p "<prompt>" does not get MCP Tasks.

The last point matters for scheduled agents. Do not turn a working interactive demonstration into a one-shot cron command and assume the client will keep following the task. Builders should use the current provider reference, including its non-interactive conditions, before designing that lifecycle.

How do you know a task completed or stopped?

Use /tasks to inspect the tracked job. The completion notice in the transcript identifies the task, but the actual result is delivered to Claude. Ask for the result and check the output itself: an export link, a build report or another concrete artifact.

To stop a task, select it in /tasks and press x, or ask Claude to stop it. Anthropic says this stops tracking and requests cancellation from the server; the server may still finish. Escape does not stop a background task. If the server disconnected, reconnect it in /mcp before requesting cancellation.

For anything with external effects, check the server as well. Closing the terminal is not an undo button, and a cancellation request is not evidence that a purchase, deployment or export was reversed. Those are reasons to choose harmless work for the first test.

What are Elicitations, and can unattended runs answer them?

Elicitation lets an MCP server request structured human input during a job. Claude Code can show a form or ask to open a browser flow. An input request is a pause in the workflow, not proof that the server failed.

For an MCP task, a dialog can be hidden while /tasks is open, so close that view to answer. The current reference also says a non-interactive session requests cancellation when a task asks for input; it does not invoke the task's Elicitation hooks or SDK callback in that case. Do not build an unattended run around a human dialog arriving later.

Review the server identity and destination before completing any sign-in. Anthropic's security guidance remains relevant when a tool requests a browser action. Never paste credentials into an agent conversation as a workaround.

Does your subscription cover the server job too?

Do not infer that. Anthropic's authentication documentation describes how Claude Code signs in; it does not make every connected service free. A report server or hosted build service can have its own account and charges.

Likewise, Claude Code's usage guide distinguishes subscription usage from API accounting. Task support does not promise a larger allowance or cost-free follow-up reasoning. Check the account route and service billing separately.

The Claude app directory helps you find compatible apps, including Conductor. A listing is not a certification that a particular app surface exposes this beta; verify the underlying session before relying on it.

What should you test before trusting a long-running job?

Start with a disposable report that cannot change production data. Record the Claude Code version, server transport and task ID. Confirm that /tasks tracks it, that Claude can retrieve the completed artifact, and that the server's documented cancellation behavior matches what you need.

Only test exit-and-resume with a remote server that documents durable work. Stop the harmless test while connected and verify the server's outcome before scheduling anything consequential. These are recommended checks, not tests we performed on a live task server. The feature is useful precisely when the lifecycle is explicit, rather than guessed from a spinner disappearing.