Tasks: io.modelcontextprotocol/tasks extension on modern servers (era fork) (#1731)

* Tasks: modern io.modelcontextprotocol/tasks extension (era fork core)

Core + test-server implementation of the SEP-2663 tasks extension for modern
(2026-07-28) connections, forked from the legacy 2025-11-25 tasks path.

SDK v2 removed all tasks support AND era-gates the tasks/* spec methods out of
the modern era on both the client (outbound) and server (inbound) sides, and its
codec rejects a resultType:"task" result outright. So the Inspector drives the
extension itself: task creation rides tools/call (a modern method) with the
resultType:"task" frame rewritten at the transport to a CallToolResult carrying
the handle in _meta; tasks/get/update/cancel go over a raw-wire request channel
that bypasses the era gate (full modern envelope, string ids, consumed by the
transport). input_required tasks reuse the existing pending-request modal via
fulfilInputRequests, answered with tasks/update. No tasks/list, no tasks/result.

Tab + run-as-task gate on the negotiated extension; the managed task store's
refresh re-polls known handles on modern (no server list). Test server serves
the extension via an Express interceptor (SDK can't) + a shared poll-driven
runtime. Full integration coverage of both eras.

Refs #1631

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Tasks modern era: tests + coverage (raw-wire, schemas, era integration)

Adds unit coverage for modernTaskSchemas and the raw-wire request channel
(transport-null guard, send failure, timeout, error response, teardown), plus
end-to-end era integration tests (create/poll/input-required/update/cancel,
synchronous passthrough, unknown-id error, modern store re-poll). Fixes the App
and constructor-capabilities tests for the always-on tasks extension.

Refs #1631

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Tasks modern era: docs + share test servers per era to de-flake coverage

Document the tasks era-fork test configs in README and the new core/test-server
files in AGENTS.md. Share one modern + one legacy test server across the era
integration block (started lazily, stopped in afterAll) — starting a fresh
Express server per test made connection negotiation flaky under the heavy
concurrent coverage run.

Refs #1631

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Restore pr-screenshots deleted inadvertently

The logging/subscriptions PR screenshots + README were staged-deleted in the
working tree before this branch; restore them from v2/main so this PR doesn't
remove other PRs' artifacts.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Tasks modern era: offer Run-as-task for any tool + PR screenshots

On modern (SEP-2663) task creation is server-directed — the client declares the
extension once and any tool may return a task — so the Tools screen now offers
'Run as task' for every tool on a modern connection (threaded via a modernTasks
prop through InspectorView → ToolsScreen → ToolDetailPanel), rather than gating
on the legacy per-tool taskSupport. Verified end-to-end in the web UI (remote
proxy): create → poll tasks/get → input_required elicitation → tasks/update →
inline result, plus the unchanged legacy tasks/list/result flow. Adds proof
screenshots.

Refs #1631

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Tasks modern era: address two follow-ups (task-input note + ordinary-path auto-poll)

1. The pending-request note now distinguishes a modern task round from an MRTR
   round: a new 'task-input-required' PendingRequestOrigin threads through
   fulfilInputRequests → the pending-request modal → MrtrOriginNote, which shows
   'submitted via a tasks/update request (SEP-2663), not a retry' instead of the
   MRTR retry copy.

2. The ordinary (non-run-as-task) modern callTool path now auto-polls an
   unsolicited task handle: attemptToolCall detects the rewritten handle in the
   result _meta and drives it to termination (get → input_required/update →
   inline result), dispatching task events so the Tasks tab + toasts track it and
   the tool result resolves to the task's final result. The poll loop is shared
   with the streaming path via extracted helpers (submitModernTaskInput /
   modernTaskTerminalOutcome / modernTaskPollInterval).

Refs #1631

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Tasks modern era: address review (negotiated envelope version, input-round cap, clarifying comment) + fresh smoke screenshots

Review of #1731:
1. withModernTaskEnvelope now stamps the NEGOTIATED protocol version
   (getProtocolVersion() ?? MODERN_PROTOCOL_VERSION) so the envelope matches the
   MCP-Protocol-Version header instead of a hardcoded constant.
2. A never-completing input_required task is now bounded by MRTR_MAX_ROUNDS in the
   shared submitModernTaskInput (threaded through both poll loops), so a
   non-conformant server can't re-prompt the user forever. New modern_loop_task
   test-server tool + integration test cover the cap.
3. ToolDetailPanel: comment clarifying that per-tool taskSupport:"forbidden" is
   deliberately ignored on modern (task creation is server-directed under SEP-2663).

(The abort-during-poll observation is addressed in the PR reply: the cancel path
uses tasks/cancel and disconnect rejects the in-flight raw request, so the poll
stops; matches legacy.)

Fresh web-UI smoke screenshots (modern connected, task completed, input_required
with the corrected tasks/update note, input completed).

Refs #1631

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Tasks modern era: fix uncancelable input-required loop + sticky cancel

Two bug fixes reported during manual testing of the tasks era-fork (#1631):

1. A modern task paused at `input_required` (e.g. `modern_loop_task`, which
   never advances) could not be cancelled: the poll loop blocked on the
   pending-request modal, so `cancelRequestorTask` sent `tasks/cancel` but the
   modal kept re-prompting. Now each modern poll loop registers a per-task
   AbortController (`registerTaskInputAbort`), `cancelRequestorTask` aborts it
   to reject the pending elicitation and unblock the poll, and the embedded
   input requests are tagged with their owning task id
   (`RELATED_TASK_META_KEY`) so the pending-request UI's Cancel action cancels
   the TASK rather than sending a "cancel" answer the server would re-prompt on.

2. On the legacy server, cancelling a task briefly showed CANCELLED then
   flipped to COMPLETED when the in-flight tool call resolved. Cancellation is
   a deliberate terminal decision, so `ManagedRequestorTasksState` now remembers
   cancelled task ids and ignores any later non-cancelled status update.

Also: move the compact task id onto its own line in the embedded monitoring
sidebar so the status badge / Cancel Task control don't wrap; DRY the duplicated
task poll-interval logic into a shared `taskPollInterval` helper.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Refresh tasks PR screenshots + capture both bug-fix scenarios

Recapture the five tasks flow screenshots against the current build and add
two demonstrating the post-review fixes: modern_loop_task cancelled from the
pending-request modal (uncancelable-loop fix) and a legacy task staying
CANCELLED after the in-flight call resolves (sticky-cancel fix).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

* Address re-review: sticky cancel on legacy refresh + App cancel-routing test

Re-review of the cancelable-loop / sticky-cancel fix raised two non-blocking
hardening items:

1. The legacy tasks/list refresh() rebuilt the list from the server, honoring
   only dismissedTaskIds — so a cooperative-cancel server that re-lists a
   user-cancelled task as completed could un-stick the cancel on a manual
   Refresh. The refresh path now pins a cancelledTaskIds task to "cancelled"
   (keeping it visible-as-cancelled, matching the live-merge handlers) rather
   than dropping it. Covered by a new state test.

2. Added an App.test.tsx case locking in the user-facing half of the fix: Cancel
   on a task-input-required elicitation calls cancelRequestorTask (not respond).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XNdjEPKLG637X8YmhDiEk5

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

clients/web/src/components/groups/TaskCard/TaskCard.stories.tsx

@@ -90,3 +90,10 @@ export const Cancelled: Story = {
 export const Collapsed: Story = {
   args: { task: workingTask, isListExpanded: false },
 };
+
+// Compact monitoring-sidebar variant: the task id moves to its own line below
+// the header so the status badge and Cancel Task control stay on the first row
+// in the narrow column (#1631).
+export const Embedded: Story = {
+  args: { task: workingTask, embedded: true },
+};

clients/web/src/components/groups/TaskCard/TaskCard.test.tsx

@@ -51,6 +51,25 @@ describe("TaskCard", () => {
     expect(screen.getByText("300000ms")).toBeInTheDocument();
   });
 
+  it("still renders the task id (on its own line) in the embedded variant (#1631)", () => {
+    // The embedded sidebar moves the id out of the header so the badge/Cancel
+    // don't wrap, but the id must remain visible (not removed entirely).
+    renderWithMantine(
+      <TaskCard
+        task={workingTask}
+        isListExpanded={false}
+        onCancel={vi.fn()}
+        embedded
+      />,
+    );
+    expect(screen.getByText("ID: task-working-1")).toBeInTheDocument();
+    // The status badge and Cancel Task control are still present on the header.
+    expect(screen.getByText("working")).toBeInTheDocument();
+    expect(
+      screen.getByRole("button", { name: "Cancel Task" }),
+    ).toBeInTheDocument();
+  });
+
   it("renders the Cancel Task button when status is working", () => {
     renderWithMantine(
       <TaskCard task={workingTask} isListExpanded={false} onCancel={vi.fn()} />,

clients/web/src/components/groups/TaskCard/TaskCard.tsx

@@ -24,6 +24,13 @@ export interface TaskCardProps {
   progress?: TaskProgress;
   isListExpanded: boolean;
   onCancel: () => void;
+  /**
+   * Compact variant for the narrow monitoring sidebar. Moves the long task ID
+   * out of the header onto its own line below it (truncated) so the header
+   * doesn't wrap the status badge / Cancel Task control onto a second row. The
+   * full-width Tasks screen keeps the ID inline in the header.
+   */
+  embedded?: boolean;
 }
 
 const TaskContainer = Card.withProps({
@@ -80,6 +87,9 @@ const HeaderLeftGroup = Group.withProps({
 
 const HeaderRightGroup = Group.withProps({
   gap: "xs",
+  // Keep the Cancel Task control and the status badge together on the header's
+  // first row rather than letting the badge wrap beneath the button.
+  wrap: "nowrap",
 });
 
 const SectionTitle = Text.withProps({
@@ -100,6 +110,7 @@ export function TaskCard({
   progress,
   isListExpanded,
   onCancel,
+  embedded = false,
 }: TaskCardProps) {
   const { taskId, status, ttl, createdAt, lastUpdatedAt, statusMessage } = task;
   const [isExpanded, setIsExpanded] = useState(isListExpanded);
@@ -115,7 +126,11 @@ export function TaskCard({
         <HeaderRow>
           <HeaderLeftGroup>
             <SectionTitle>Task Details</SectionTitle>
-            <TaskIdText>{formatTaskId(taskId)}</TaskIdText>
+            {/* Full-width screen: the id sits inline after the title. In the
+                narrow embedded sidebar it moves to its own line below (see
+                below) so it can't push the status badge / Cancel Task onto a
+                second row. */}
+            {!embedded && <TaskIdText>{formatTaskId(taskId)}</TaskIdText>}
           </HeaderLeftGroup>
           <HeaderRightGroup>
             {isActive && (
@@ -125,6 +140,10 @@ export function TaskCard({
           </HeaderRightGroup>
         </HeaderRow>
 
+        {embedded && (
+          <TaskIdText truncate="end">{formatTaskId(taskId)}</TaskIdText>
+        )}
+
         <SummaryRow>
           <DetailRow>
             <Stack gap={2}>

clients/web/src/components/groups/TaskListPanel/TaskListPanel.tsx

@@ -135,6 +135,7 @@ export function TaskListPanel({
                     progress={progressByTaskId?.[task.taskId]}
                     isListExpanded={!compact}
                     onCancel={() => onCancel(task.taskId)}
+                    embedded={embedded}
                   />
                 ))}
               </>
@@ -157,6 +158,7 @@ export function TaskListPanel({
                     progress={progressByTaskId?.[task.taskId]}
                     isListExpanded={!compact}
                     onCancel={() => onCancel(task.taskId)}
+                    embedded={embedded}
                   />
                 ))}
               </>

clients/web/src/components/groups/ToolDetailPanel/ToolDetailPanel.test.tsx

@@ -325,6 +325,42 @@ describe("ToolDetailPanel", () => {
       expect(screen.queryByLabelText("Run as task")).not.toBeInTheDocument();
     });
 
+    it("shows the toggle for a task-forbidden tool on a modern connection (#1631)", () => {
+      // On modern (SEP-2663) task creation is server-directed, so any tool can
+      // become a task — the toggle is offered regardless of per-tool taskSupport.
+      renderWithMantine(
+        <ToolDetailPanel
+          {...baseProps}
+          tool={toolWithSupport("forbidden")}
+          serverSupportsTaskToolCalls={true}
+          modernTasks={true}
+          runAsTask={false}
+        />,
+      );
+      const toggle = screen.getByLabelText("Run as task");
+      expect(toggle).not.toBeChecked();
+      expect(toggle).not.toBeDisabled();
+    });
+
+    it("routes the user's runAsTask choice on a modern connection (#1631)", async () => {
+      const user = userEvent.setup();
+      const onExecute = vi.fn();
+      renderWithMantine(
+        <ToolDetailPanel
+          {...baseProps}
+          tool={toolWithSupport("forbidden")}
+          serverSupportsTaskToolCalls={true}
+          modernTasks={true}
+          runAsTask={true}
+          onExecute={onExecute}
+        />,
+      );
+      // The toggle is checked (user's choice), and executing forwards true.
+      expect(screen.getByLabelText("Run as task")).toBeChecked();
+      await user.click(screen.getByRole("button", { name: "Execute Tool" }));
+      expect(onExecute).toHaveBeenCalledWith(true);
+    });
+
     it("shows an unchecked, enabled toggle for an optional tool (off by default)", () => {
       renderWithMantine(
         <ToolDetailPanel

clients/web/src/components/groups/ToolDetailPanel/ToolDetailPanel.tsx

@@ -35,7 +35,15 @@ export interface ToolDetailPanelProps {
   progress?: ToolProgress;
   /** Whether the connected server advertises task-augmented tool calls. */
   serverSupportsTaskToolCalls: boolean;
-  /** User's "Run as task" preference (only meaningful for `optional` tools). */
+  /**
+   * Modern (2026-07-28) connection with the `io.modelcontextprotocol/tasks`
+   * extension negotiated (SEP-2663). Task creation is server-directed there, so
+   * "Run as task" is offered for ANY tool (not just ones declaring per-tool
+   * `taskSupport`, which is the legacy mechanism). Defaults to false (legacy).
+   */
+  modernTasks?: boolean;
+  /** User's "Run as task" preference (meaningful for `optional` tools and, on
+   * modern connections, any tool). */
   runAsTask: boolean;
   onRunAsTaskChange: (value: boolean) => void;
   onFormChange: (values: Record<string, unknown>) => void;
@@ -154,6 +162,7 @@ export function ToolDetailPanel({
   isExecuting,
   progress,
   serverSupportsTaskToolCalls,
+  modernTasks = false,
   runAsTask,
   onRunAsTaskChange,
   onFormChange,
@@ -180,20 +189,28 @@ export function ToolDetailPanel({
   // single expandable control (aria-expanded + aria-controls).
   const descriptionRegionId = useId();
 
-  // Show the toggle only when the server supports task tool calls and the tool
-  // doesn't forbid them. `required` tools are forced on (checked + disabled);
-  // `optional` tools follow the user's `runAsTask` choice.
+  // Show the toggle when the server supports task tool calls and either the
+  // connection is modern (task creation is server-directed there, so any tool
+  // may become a task) or the tool doesn't forbid per-tool task support
+  // (legacy). `required` tools are forced on (checked + disabled); `optional`
+  // and (on modern) any tool follow the user's `runAsTask` choice.
+  //
+  // NOTE: on modern, a per-tool `taskSupport: "forbidden"` is DELIBERATELY
+  // ignored. Under SEP-2663 task creation is decided by the server per request,
+  // not declared per tool, so `taskSupport` (a legacy 2025-11-25 concept) does
+  // not gate the affordance — the server may return a task for any call. The
+  // toggle just declares intent to poll a returned handle.
   const taskSupport = getTaskSupport(tool);
   const showRunAsTask =
-    serverSupportsTaskToolCalls && taskSupport !== "forbidden";
-  // Gate the effective decision on `showRunAsTask` (which includes
-  // `serverSupportsTaskToolCalls`): a stale `runAsTask`/`required` value must
-  // not route through callToolStream when the toggle is hidden because the
-  // server doesn't advertise task tool calls. Per spec, a tool's taskSupport is
-  // only considered when the server advertises `tasks.requests.tools.call`.
+    serverSupportsTaskToolCalls && (modernTasks || taskSupport !== "forbidden");
+  // Gate the effective decision on `showRunAsTask`: a stale `runAsTask`/`required`
+  // value must not route through callToolStream when the toggle is hidden. On
+  // legacy, a tool's taskSupport is only considered when the server advertises
+  // `tasks.requests.tools.call`; on modern, the user's choice governs any tool.
   const effectiveRunAsTask =
     showRunAsTask &&
-    (taskSupport === "required" || (taskSupport === "optional" && runAsTask));
+    (taskSupport === "required" ||
+      ((taskSupport === "optional" || modernTasks) && runAsTask));
 
   return (
     <PanelStack>