Claude Code v2.1.310 Major Updates - Monitor Tool Support for Bedrock, Vertex, and Foundry, and Blocking of Long-Duration Sleep

This is Ishikawa from the Cloud Business Division. Claude Code v2.1.310 (released October 23, 2026) has been released. This article introduces the key updates. We also explain the early access to MCP Tasks and Elicitations for Claude Code, as announced on X.

The previous update article is here.

https://dev.classmethod.jp/articles/20261023-cc-updates-v2-1-309/

Update Summary

v2.1.310 includes 26 changes. In this article's classification, there are 12 fixes, 8 improvements, 3 new features, 2 security updates, and 1 performance improvement.

The new features include 1 for the Monitor tool and 2 for Cloud sessions. The 2 security updates are fixes related to permission prompts and hooks. No breaking changes or deprecations are explicitly noted in the CHANGELOG, but the blocking of long-duration sleep included in the Monitor items is treated under "Breaking Changes & Deprecations" as a behavioral change for affected environments. There are also changes to the VS Code extension, Cloud sessions, Claude Tag, and Code Review.

Notable Updates

Monitor Tool Now Available on Bedrock, Vertex, Foundry, and When Telemetry Is Disabled

The Monitor tool and plugin monitors are now available on Bedrock, Vertex, Foundry, and in environments where telemetry or nonessential traffic is disabled. Additionally, long-duration foreground sleep is now blocked in these environments as well.

According to the official documentation (Tools reference), the Monitor tool runs commands in the background and returns each line of output to Claude, and is used for monitoring log files or polling the status of PRs and CI jobs. As of the time of writing (October 24, 2026), the documentation still states that it is not available on Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry, and also not available when DISABLE_TELEMETRY or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set. The blocking of sleep is covered under "Breaking Changes & Deprecations."

For those using Claude Code via Bedrock, Vertex, or Foundry, or operating with telemetry disabled, Monitor adds more options for monitoring and waiting, while the approach of having Claude wait with a long sleep will be blocked—something worth being aware of.

Cloud Session and Remote Control Permissions Added to Enterprise Custom Roles

Cloud session and Remote Control permissions for Claude Code have been added to Enterprise custom roles, allowing Owners to control access to each on a per-role basis. Additionally, when enabling Cloud sessions or Remote Control in admin settings, a confirmation is now required and the custom roles with those permissions are listed.

For Owners who want to open Cloud sessions or Remote Control only to certain roles in their Enterprise, this makes phased rollouts via custom roles easier.

Fixed Issue Where Requests Failed on Some Gateways and Compatible Servers

An issue where requests failed because some gateways and compatible servers rejected the beta value effort-2025-11-24 or mid-conversation system messages has been fixed. Claude Code will now retry without these.

For those using Claude Code via an LLM gateway or compatible server who have been experiencing persistent request failures, it is worth checking whether updating resolves the issue.

Fixed Issue Where Symlink Target Was Not Shown in File Read Permission Prompt

An issue where the symlink target was not displayed in the file read permission prompt has been fixed.

According to the official documentation (Configure permissions), for paths that go through a symlink, both the path Claude requested and the file the link resolves to are subject to permission checks. Reading a symlink that is within an allowed directory but points outside of it does not match an allow rule.

For those who have symlinks in their working directory, you can now verify the link target in the permission prompt before approving, making it easier to avoid accidentally having Claude read files in unintended locations.

Fixed Issue Where PreToolUse / PermissionRequest Hooks Let Tool Calls Through on Windows

An issue where PreToolUse and PermissionRequest hooks let tool calls through on Windows when Git Bash is not present and the hook command consists only of a quoted string (such as a quoted path) has been fixed.

For those using hooks on Windows without Git Bash, hooks written with only a quoted path as the command may not have been blocking tool calls, making this a fix worth picking up promptly.

Deep Dive: MCP Tasks and Elicitations

The official developer account for Claude, ClaudeDevs, announced in an X thread that MCP Tasks and Elicitations are being made available early in Claude Code.

https://x.com/ClaudeDevs/status/2113698005161533504

The thread consists of 3 posts. The first and second posts include demo videos. The Claude Code CLI is receiving the feature first, with other Claude products to follow.

https://code.claude.com/docs/en/mcp

How MCP Tasks Work

An MCP task is a long-running job—like exporting a report or running a build—that the MCP server executes itself using the MCP tasks extension.

• Because Claude's tool call returns as soon as the server accepts the job, Claude can continue working without waiting for the job to complete. When the job finishes, this is shown in the transcript and Claude receives the result.
• While running, a count like 1 MCP task is shown in the footer, and Claude Code polls the server for status to track the task.
• Tasks running on a remote server continue executing even if Claude Code is closed. Resuming the same session allows tracking to resume.

Conditions for Using MCP Tasks

The official documentation lists the following conditions, all of which must be met for a tool call to become an MCP task:

• The server supports tasks
• The server is connected via HTTP, stdio, or the claude.ai connector using protocol revision 2026-07-28 (setting MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy disqualifies it)
• The session receives the feature flag (third-party providers such as Amazon Bedrock, and environments with telemetry or feature flag fetching disabled, are excluded)
• Anthropic has enabled MCP tasks for that session type. From v2.1.304 onward, terminal CLI sessions, Agent SDK sessions, and GitHub Actions runs are eligible; VS Code extension and desktop app are not
• The call is made from the main conversation (calls from sub-agents are excluded)
• It is an interactive session, or an Agent SDK session or claude -p run reading input with --input-format stream-json, with CLAUDE_AUTO_BACKGROUND_TASKS set to 1, CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND set to something other than 1, and CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS set to something other than 0

MCP tasks are not used in one-shot claude -p "<prompt>" runs. Also, as noted in the third condition, Bedrock and telemetry-disabled environments—which gained Monitor tool support in v2.1.310—are also excluded from MCP tasks per the documentation at time of writing.

Having Claude Wait for Task Results

To have Claude wait for task results in an interactive session, set one of the following environment variables, for example in the env block of settings.json:

If Esc is pressed while waiting, or if the tool call's time limit (wall-clock limit or idle timeout) is reached, the call ends and Claude Code asks the server to cancel the task. Below is an example settings.json configuration that sets CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS to 0:

{
  "env": {
    "CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS": "0"
  }
}

How Elicitations Work

According to the official documentation, when an MCP server needs information it cannot obtain itself, it uses Elicitations to request structured input from the user mid-task. Claude Code displays an interactive dialog and returns the user's response to the server. No configuration is required on the user's side.

This is an MCP protocol mechanism by which an MCP server requests user input during tool processing. Claude Code displays a dialog and returns the response to the MCP server. Examples include "confirming a refund," "entering missing information," and—as shown in the Connect Claude Code to tools via MCP documentation—a username and password form, or signing in via a browser.

• To respond automatically without displaying a dialog, use the Elicitation hook.
• For connections using protocol revision 2026-07-28, Claude Code declares elicitation: {form: {}, url: {}} in the client capabilities.
• When an MCP task's status becomes input_required, elicitation/create requests contained in inputRequests are only processed in interactive terminal sessions. If they cannot be processed, Claude Code asks the server to cancel the task.
• In v2.1.310, the error when an MCP tool call times out without a response to a server elicitation in a non-interactive session has been changed to inform Claude that no response was received and that the call should not be retried (see Improvements under "Update Details").

Interaction Between Tasks and Elicitations

MCP Tasks and Elicitations are connected through task state. When the server requires user input during task execution, it sets the status to input_required in the tasks/get response and includes an elicitation request (elicitation/create) in inputRequests. Claude Code displays this as a dialog and returns the user's response to the server via tasks/update. Based on the official documentation's explanation for server authors, this flow can be diagrammed as follows:

The diagram shows the case where input is requested mid-task. Since Elicitations have been available in Claude Code since v2.1.76, before MCP tasks, servers can also request input via elicitation requests during tool calls that do not use tasks.

Update Details

New Features

• The Monitor tool and plugin monitors are now available on Bedrock, Vertex, Foundry, and in environments where telemetry or nonessential traffic is disabled (see Notable Updates).
• [Cloud sessions] Cloud session and Remote Control permissions have been added to Enterprise custom roles (see Notable Updates).
• [Cloud sessions] A "Choose file" button has been added to load the cloud environment setup script from a file.

Security

• Fixed issue where symlink target was not shown in file read permission prompt: See Notable Updates
• Fixed issue where PreToolUse / PermissionRequest hooks let tool calls through on Windows without Git Bash: See Notable Updates

Improvements

• The prompt shown in auto mode before the first read outside the working directory has been improved to indicate when blocking that read would result in permission being requested via a shell command.
• On Linux, when Ubuntu's AppArmor restriction on user namespaces prevents bubblewrap from starting the sandbox, the /sandbox message and sandbox startup warning now indicate the restriction and how to disable it.
• In non-interactive sessions, the error when an MCP tool call times out without a response to a server elicitation has been changed to inform Claude that no response was received and that the call should not be retried.
• [Cloud sessions] When enabling Cloud sessions or Remote Control in admin settings, a confirmation is now required and the custom roles with those permissions are listed (see Notable Updates).
• Additional improvements and changes have been made to the mod Image rendering (inside tmux with allow-passthrough and focus-events enabled, fullscreen rendering in kitty, Ghostty, and iTerm2 3.5 or later), the setup script output display and cloud environment dialog layout in Cloud sessions, and the retry behavior on first load of the Code Review admin section.

Performance

• Memory usage during compaction when transcript files are very large in non-interactive sessions (-p, Agent SDK) has been improved.

Fixes

• Fixed issue where requests failed on some gateways and compatible servers: See Notable Updates
• Fixed issue where very large cleanupPeriodDays caused recent files to be deleted: When cleanupPeriodDays was set to a very large value, background cleanup was deleting some recent files such as pasted images
• Fixed issue where compaction after "Prompt is too long" error left too much of the conversation: In conversations containing dense text such as base64 or SVG, too much of the conversation was retained after compaction, causing the next request to fail again
• [VS Code] Fixed issue where pressing Enter on the plan review card approved the plan: Pressing Enter on the "Send feedback and keep planning" button was approving the plan instead of returning a comment
• A quietly appreciated fix: An issue where the auto-continue timeout fired the moment an external editor was closed after a long editing session has been fixed. For those who take time writing responses to questions in an external editor, this is a quietly appreciated fix.
• Additional minor bugs have been fixed in the VS Code extension (display after "Switch branch & continue" in cloud sessions), Cloud sessions (cloud environment edit dialog, routine API token operations), Claude Tag (formatted ! commands, admin screen display), and the Code Review admin section, among others.

Breaking Changes & Deprecations

No breaking changes or deprecations are explicitly noted in the CHANGELOG. This section covers the behavioral change in affected environments included in the Monitor new feature item (listed as "Added" in the CHANGELOG).

Long-Duration Foreground Sleep Blocked on Bedrock, Vertex, Foundry, and When Telemetry Is Disabled

In environments where the Monitor tool is now available, long-duration foreground sleep is now also blocked. The phrasing "there too" in the CHANGELOG suggests that this was already being blocked in other environments (inferred). The following compares the before and after behavior:

Before (up to v2.1.309):

Target: Bedrock, Vertex, Foundry, or environments with telemetry or nonessential traffic disabled
Monitor tool / plugin monitors → Not available (as stated in official documentation at time of writing)
Long-duration foreground sleep → Not noted in CHANGELOG or documentation; unconfirmed

After (v2.1.310 onward):

Target: Same environments
Monitor tool / plugin monitors → Available
Long-duration foreground sleep → Blocked

When requesting sleep 120 execution in a claude -p run with CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 or DISABLE_TELEMETRY=1 set, on Claude Code v2.1.310 on macOS (connected directly to the Anthropic API), the following message was shown and the command was blocked:

Blocked: standalone sleep 120. To wait for a condition, use Monitor with an until-loop (e.g. `until <check>; do sleep 2; done`). To wait for a command you started, use run_in_background: true. Do not chain shorter sleeps to work around this block.

The message advises using a Monitor until loop to wait for a condition, using run_in_background: true to wait for a command you started, and instructs not to chain shorter sleeps to work around the block. The threshold for what counts as "long-duration" is not stated in the CHANGELOG or documentation. Behavior on Bedrock, Vertex, and Foundry has not been verified.

Closing

From a CHANGELOG perspective, this release feels centered on expanding the Monitor tool to Bedrock, Vertex, Foundry, and telemetry-disabled environments. At the same time, the fixes around permissions—such as displaying symlink targets and hooks on Windows—are also worth reviewing.

For those using Claude Code via Bedrock, Vertex, or Foundry, or with telemetry disabled, we recommend checking the Breaking Changes & Deprecations section before updating and giving it a try.

References

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

https://code.claude.com/docs/en/changelog

https://dev.classmethod.jp/articles/20261023-cc-updates-v2-1-309/