Claude Code now runs MCP tasks and asks elicitation questions. What that means when nobody is at the keyboard

You have an MCP tool that takes ten minutes: a report export, a build, a deep research run. Until this week, the server had to hold that request open for the whole ten minutes. Now a server can answer at once with a task, Claude keeps working, and the result arrives later. The same server can also stop and ask you something, like "Deploy to staging?".

That is good news at a desk. It is less obvious what happens when the agent runs on a schedule, in CI, or in a container that nobody is watching. This post covers what Anthropic shipped, what the docs say about headless runs, and what to set. We make Sessionboxer, and the last section says how it fits and where it does not.

What shipped

On 23 October 2026 Anthropic's ClaudeDevs account announced support for MCP Tasks and Elicitations: "Tasks let Claude give plugins long-running jobs such as deep research and report back when they're done", and elicitations "let plugins ask users for input mid-task". Both are available in the Claude Code CLI, with other Claude products to follow. Upstash's write-up adds that David Soria Parra, co-creator of MCP, announced Tasks support in his keynote at MCPCon North America the day before.

The protocol side is the MCP Tasks extension (SEP-2663, now Final). A server can answer a tools/call with a task handle instead of a result. The client then polls tasks/get until the task is completed, failed or cancelled, and can call tasks/cancel. A task can also sit in input_required, which is where elicitation comes in.

According to the Claude Code MCP docs, MCP tasks are a public beta and need Claude Code 2.1.304 or later. In practice:

• The footer shows a count such as 1 MCP task, and /tasks lists them. Select one and press x to stop it.
• When a task ends, the transcript shows MCP task <id> (<server>/<tool>) completed. The result goes to Claude, not into the transcript. If Claude is idle, it starts on the result without a new prompt.
• A task on a remote server keeps running after you exit. Resume the same session interactively and Claude Code follows it again.
• A stdio server's process stops when Claude Code exits, so its tasks usually die with it unless that server says otherwise.

Elicitation has two modes. Form mode shows a dialog with fields the server defines. URL mode asks whether to open a link, for sign-ins and other flows that finish in the browser. Declining or pressing Esc counts as an answer, and the server decides what to do next.

Where tasks work and where they do not

The docs list every condition for a call to become an MCP task. The ones that matter most:

Everything else is a plain tool call. Separately, Claude Code moves a main-conversation MCP call that is still running after two minutes into the background, with no change on the server. That background call does not survive exiting the session, and the per-call time limits still apply.

Headless runs: the part to read twice

If you run Claude Code with claude -p from cron, a CI job or a script, the docs are specific:

• A one-shot claude -p "<prompt>" run does not get MCP tasks. The long call blocks as before.
• An Agent SDK session, or a claude -p run reading --input-format stream-json, gets tasks only with CLAUDE_AUTO_BACKGROUND_TASKS=1, and with CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND and CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS not turned off.
• Keep that session's input open. The run does not wait for MCP tasks after input closes, so a script that sends one prompt and closes stdin can end before the result comes back.
• In a non-interactive session, a task that asks for input is cancelled. Claude Code asks the server to cancel it, and it does not run your Elicitation hooks or the Agent SDK's onElicitation callback for it.

The last point is the one that bites. Picture a nightly job that calls a deploy tool, and the server author has just added a confirmation question. Interactively, you would see a dialog. In the nightly run, Claude Code asks the server to cancel the task. Nothing was deployed, and nobody was asked. That is the safe outcome, but your job did not do what it did yesterday.

Claude Code 2.1.310, released the same day, touches the plain-call version of this: when an MCP call times out in a non-interactive session while the server's elicitation is unanswered, Claude is now told that no answer came and not to repeat the call.

What to do this week

If you write MCP servers:

1. Return a task only when the request's client capabilities include io.modelcontextprotocol/tasks. Otherwise Claude gets the error Unsupported result type 'task' for tools/call.
2. Keep task IDs valid across connections. After a resume, Claude Code asks about the task on a new connection.
3. Do not make a confirmation question the only way to proceed. Give the tool an argument that carries the answer, so a headless caller can say "yes, staging" up front, and treat a cancelled task as "nothing happened" in your own logs.

If you run agents unattended:

1. Check whether any server you use has started asking questions. Its changelog is the place to look. A job that used to finish may now end with a cancelled task.
2. If you want tasks in an Agent SDK or stream-json run, set CLAUDE_AUTO_BACKGROUND_TASKS=1 and keep input open until the task result arrives.
3. If you would rather the run wait for every MCP call, as before, set CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS to 0 in the env block of settings.json.
4. For interactive use where you want to answer some questions automatically, write an Elicitation hook. Remember it does not fire for task questions in headless runs.
5. Prefer remote HTTP servers for jobs that outlive the session. A stdio server's process stops when Claude Code exits.

The docs also have a table of status messages for tasks Claude Code cannot reach, ending in outcome unknown. That line means a second call may repeat the work. Before running the tool again, find out from the server what was already done.

Where Sessionboxer fits, and where it does not

Sessionboxer runs Claude Code in a container per session and talks to it through the Agent Client Protocol adapter, which is built on the Agent SDK. You register MCP servers once and switch them on per session; command-based servers run inside the box, and HTTP servers are reached from it. The MCP servers chapter of the guide has the details.

What that means for this release, plainly:

• Sessionboxer does not set CLAUDE_AUTO_BACKGROUND_TASKS for the agent. By the docs above, an Agent SDK session without it gets plain tool calls, so an MCP task server behaves the way it did last week.
• Sessionboxer's chat has no form for MCP elicitations. Server-to-agent requests go to the agent, and we have not tested what the adapter does with an elicitation. If a server relies on asking you mid-call, treat it as unsupported in Sessionboxer for now.
• A command-based server runs inside the box, so when you stop a session, its process stops too. Resume brings the box back with the conversation, but not a job that lived in that process.

Sessionboxer has a different MCP feature that overlaps with the "tell me when it is done" idea. An automation can trigger "when an MCP server reports an event", for servers that offer the experimental MCP Events extension. The Control Plane keeps its own connection to the server, so events arrive with no session running, and each one can prompt a session or start a new one. The Automations chapter describes the limits and the event placeholders. It is not MCP Tasks, and it only works with servers that offer events.

If your agent runs on a timer, running Claude Code on a schedule covers the rest of that setup. If the server lives on your own machine and the agent is in a container, connecting the two is the post to read first.