Developer Platform Release Notes

Subrequests limits

Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests
to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as
open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.

By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this
limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.

wrangler.jsonc

{
"limits": {
"subrequests": 50000,
},
}

wrangler.toml

[limits]
subrequests = 50_000

Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.

To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

wrangler.jsonc

{
"limits": {
"subrequests": 10,
"cpu_ms": 1000,
},
}

wrangler.toml

[limits]
subrequests = 10
cpu_ms = 1_000

For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.

Original source Report a problem

The Cloudflare Vite plugin integration

The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc, the official Vite plugin for React Server Components.

A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker.

The parent environment can then import modules from a child environment in order to access a separate module graph.

For a typical RSC use case, the plugin might be configured as in the following example:

export default defineConfig({
  plugins: [
    cloudflare({
      viteEnvironment: {
        name: "rsc",
        childEnvironments: ["ssr"],
      },
    }),
  ],
});

@vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router, build upon.

The GitHub repository includes a basic Cloudflare example.

Original source Report a problem

The latest release of the Agents SDK brings readonly connections, MCP protocol and security improvements, x402 payment protocol v2 migration, and the ability to customize OAuth for MCP server connections.

Readonly connections

Agents can now restrict WebSocket clients to read-only access, preventing them from modifying agent state. This is useful for dashboards, spectator views, or any scenario where clients should observe but not mutate.

New hooks: shouldConnectionBeReadonly, setConnectionReadonly, isConnectionReadonly. Readonly connections block both client-side setState() and mutating @callable() methods, and the readonly flag survives hibernation.

JavaScript

class MyAgent extends Agent {
  shouldConnectionBeReadonly(connection) {
    // Make spectators readonly
    return connection.url.includes("spectator");
  }
}

TypeScript

class MyAgent extends Agent {
  shouldConnectionBeReadonly(connection) {
    // Make spectators readonly
    return connection.url.includes("spectator");
  }
}

Custom MCP OAuth providers

The new createMcpOAuthProvider method on the Agent class allows subclasses to override the default OAuth provider used when connecting to MCP servers. This enables custom authentication strategies such as pre-registered client credentials or mTLS, beyond the built-in dynamic client registration.

JavaScript

class MyAgent extends Agent {
  createMcpOAuthProvider(callbackUrl) {
    return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);
  }
}

TypeScript

class MyAgent extends Agent {
  createMcpOAuthProvider(callbackUrl: string): AgentMcpOAuthProvider {
    return new MyCustomOAuthProvider(this.ctx.storage, this.name, callbackUrl);
  }
}

MCP SDK upgrade to 1.26.0

Upgraded the MCP SDK to 1.26.0 to prevent cross-client response leakage. Stateless MCP Servers should now create a new McpServer instance per request instead of sharing a single instance. A guard is added in this version of the MCP SDK which will prevent connection to a Server instance that has already been connected to a transport. Developers will need to modify their code if they declare their McpServer instance as a global variable.

MCP OAuth callback URL security fix

Added callbackPath option to addMcpServer to prevent instance name leakage in MCP OAuth callback URLs. When sendIdentityOnConnect is false, callbackPath is now required — the default callback URL would expose the instance name, undermining the security intent. Also fixes callback request detection to match via the state parameter instead of a loose /callback URL substring check, enabling custom callback paths.

Deprecate onStateUpdate in favor of onStateChanged

onStateChanged is a drop-in rename of onStateUpdate (same signature, same behavior). onStateUpdate still works but emits a one-time console warning per class. validateStateChange rejections now propagate a CF_AGENT_STATE_ERROR message back to the client.

x402 v2 migration

Migrated the x402 MCP payment integration from the legacy x402 package to @x402/core and @x402/evm v2.

Breaking changes for x402 users:

• Peer dependencies changed: replace x402 with @x402/core and @x402/evm
• PaymentRequirements type now uses v2 fields (e.g. amount instead of maxAmountRequired)
• X402ClientConfig.account type changed from viem.Account to ClientEvmSigner (structurally compatible with privateKeyToAccount())
• npm uninstall x402
• npm install @x402/core @x402/evm

Network identifiers now accept both legacy names and CAIP-2 format:

• // Legacy name (auto-converted)

  {
    "network": "base-sepolia"
  }
  

• // CAIP-2 format (preferred)

  {
    "network": "eip155:84532"
  }
  

Other x402 changes:

• X402ClientConfig.network is now optional — the client auto-selects from available payment requirements
• Server-side lazy initialization: facilitator connection is deferred until the first paid tool invocation
• Payment tokens support both v2 (PAYMENT-SIGNATURE) and v1 (X-PAYMENT) HTTP headers
• Added normalizeNetwork export for converting legacy network names to CAIP-2 format
• Re-exports PaymentRequirements, PaymentRequired, Network, FacilitatorConfig, and ClientEvmSigner from agents/x402

Other improvements

• Fix useAgent and AgentClient crashing when using basePath routing
• CORS handling delegated to partyserver's native support (simpler, more reliable)
• Client-side onStateUpdateError callback for handling rejected state updates

Upgrade

To update to the latest version:

npm i agents@latest

Original source Report a problem

The Sandbox SDK PTY passthrough

The Sandbox SDK now supports PTY (pseudo-terminal) passthrough, enabling browser-based terminal UIs to connect to sandbox shells via WebSocket.

sandbox.terminal(request)

The new terminal() method proxies a WebSocket upgrade to the container's PTY endpoint, with output buffering for replay on reconnect.

JavaScript

// Worker: proxy WebSocket to container terminal
return sandbox.terminal(request, { cols: 80, rows: 24 });

TypeScript

// Worker: proxy WebSocket to container terminal
return sandbox.terminal(request, { cols: 80, rows: 24 });

Multiple terminals per sandbox

Each session can have its own terminal with an isolated working directory and environment, so users can run separate shells side-by-side in the same container.

JavaScript

// Multiple isolated terminals in the same sandbox
const dev = await sandbox.getSession("dev");
return dev.terminal(request);

TypeScript

// Multiple isolated terminals in the same sandbox
const dev = await sandbox.getSession("dev");
return dev.terminal(request);

xterm.js addon

The new @cloudflare/sandbox/xterm export provides a SandboxAddon for xterm.js with automatic reconnection (exponential backoff + jitter), buffered output replay, and resize forwarding.

JavaScript

import { SandboxAddon } from "@cloudflare/sandbox/xterm";
const addon = new SandboxAddon({
  getWebSocketUrl: ({ sandboxId, origin }) =>
    `${origin}/ws/terminal?id=${sandboxId}`,
  onStateChange: (state, error) => updateUI(state),
});
terminal.loadAddon(addon);
addon.connect({ sandboxId: "my-sandbox" });

TypeScript

import { SandboxAddon } from "@cloudflare/sandbox/xterm";
const addon = new SandboxAddon({
  getWebSocketUrl: ({ sandboxId, origin }) =>
    `${origin}/ws/terminal?id=${sandboxId}`,
  onStateChange: (state, error) => updateUI(state),
});
terminal.loadAddon(addon);
addon.connect({ sandboxId: "my-sandbox" });

Upgrade

To update to the latest version:

npm i @cloudflare/sandbox@latest

Original source Report a problem

Reindex individual files without a full sync

Updated a file or need to retry one that errored? When you know exactly which file changed, you can now reindex it directly instead of rescanning your entire data source.

Go to Overview > Indexed Items and select the sync icon next to any file to reindex it immediately.

Crawl only the sitemap you need

By default, AI Search crawls all sitemaps listed in your robots.txt, up to the maximum files per index limit. If your site has multiple sitemaps but you only want to index a specific set, you can now specify a single sitemap URL to limit what the crawler visits.

For example, if your robots.txt lists both blog-sitemap.xml and docs-sitemap.xml, you can specify just https://example.com/docs-sitemap.xml to index only your documentation.

Configure your selection anytime in Settings > Parsing options > Specific sitemaps, then trigger a sync to apply the changes.

Learn more about indexing controls and website crawling configuration.

Original source Report a problem

The Workers Observability dashboard has some major updates to make it easier to debug your application's issues and share findings with your team.

You can now:

• Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab
• Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates
• Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
• Customize table columns — Improved field picker to add, remove, and reorder columns in the events table
• Expandable event details — Expand events inline to view full details without leaving the table
• Keyboard shortcuts — Navigate the dashboard with hotkey support

These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.

Original source Report a problem

Cloudflare Queues on the Free Plan

Cloudflare Queues is now part of the Workers free plan, offering guaranteed message delivery across up to 10,000 queues to either Cloudflare Workers or HTTP pull consumers. Every Cloudflare account now includes 10,000 operations per day across reads, writes, and deletes. For more details on how each operation is defined, refer to Queues pricing.

All features of the existing Queues functionality are available on the free plan, including unlimited event subscriptions. Note that the maximum retention period on the free tier, however, is 24 hours rather than 14 days.

If you are new to Cloudflare Queues, follow this guide or try one of our tutorials to get started.

Original source Report a problem

Cloudflare Workflows now automatically generates visual diagrams from your code

Your Workflow is parsed to provide a visual map of the Workflow structure, allowing you to:

• Understand how steps connect and execute
• Visualize loops and nested logic
• Follow branching paths for conditional logic

You can collapse loops and nested logic to see the high-level flow, or expand them to see every step.

Workflow diagrams are available in beta for all JavaScript and TypeScript Workflows. Find your Workflows in the Cloudflare dashboard to see their diagrams.

Original source Report a problem

Cloudflare Workflows integration

Agents excel at real-time communication and state management. Workflows excel at durable execution. Together, they enable powerful patterns where Agents handle WebSocket connections while Workflows handle long-running tasks, retries, and human-in-the-loop flows.

Use the new AgentWorkflow class to define workflows with typed access to your Agent:

JavaScript

import { AgentWorkflow } from "agents/workflows";
export class ProcessingWorkflow extends AgentWorkflow {
  async run(event, step) {
    // Call Agent methods via RPC
    await this.agent.updateStatus(event.payload.taskId, "processing");
    // Non-durable: progress reporting to clients
    await this.reportProgress({ step: "process", percent: 0.5 });
    this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
    // Durable via step: idempotent, won't repeat on retry
    await step.mergeAgentState({ taskProgress: 0.5 });
    const result = await step.do("process", async () => {
      return processData(event.payload.data);
    });
    await step.reportComplete(result);
    return result;
  }
}

TypeScript

import { AgentWorkflow } from "agents/workflows";
import type { AgentWorkflowEvent, AgentWorkflowStep } from "agents/workflows";
export class ProcessingWorkflow extends AgentWorkflow<MyAgent, TaskParams> {
  async run(event: AgentWorkflowEvent<TaskParams>, step: AgentWorkflowStep) {
    // Call Agent methods via RPC
    await this.agent.updateStatus(event.payload.taskId, "processing");
    // Non-durable: progress reporting to clients
    await this.reportProgress({ step: "process", percent: 0.5 });
    this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
    // Durable via step: idempotent, won't repeat on retry
    await step.mergeAgentState({ taskProgress: 0.5 });
    const result = await step.do("process", async () => {
      return processData(event.payload.data);
    });
    await step.reportComplete(result);
    return result;
  }
}

Start workflows from your Agent with runWorkflow() and handle lifecycle events:

JavaScript

export class MyAgent extends Agent {
  async startTask(taskId, data) {
    const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", {
      taskId,
      data,
    });
    return { instanceId };
  }
  async onWorkflowProgress(workflowName, instanceId, progress) {
    this.broadcast(JSON.stringify({ type: "progress", progress }));
  }
  async onWorkflowComplete(workflowName, instanceId, result) {
    console.log(`Workflow ${instanceId} completed`);
  }
  async onWorkflowError(workflowName, instanceId, error) {
    console.error(`Workflow ${instanceId} failed:`, error);
  }
}

TypeScript

export class MyAgent extends Agent {
  async startTask(taskId: string, data: string) {
    const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", {
      taskId,
      data,
    });
    return { instanceId };
  }
  async onWorkflowProgress(
    workflowName: string,
    instanceId: string,
    progress: unknown,
  ) {
    this.broadcast(JSON.stringify({ type: "progress", progress }));
  }
  async onWorkflowComplete(
    workflowName: string,
    instanceId: string,
    result?: unknown,
  ) {
    console.log(`Workflow ${instanceId} completed`);
  }
  async onWorkflowError(
    workflowName: string,
    instanceId: string,
    error: unknown,
  ) {
    console.error(`Workflow ${instanceId} failed:`, error);
  }
}

Key workflow methods on your Agent:

• runWorkflow(workflowName, params, options?) — Start a workflow with optional metadata
• getWorkflow(workflowId) / getWorkflows(criteria?) — Query workflows with cursor-based pagination
• approveWorkflow(workflowId) / rejectWorkflow(workflowId) — Human-in-the-loop approval flows
• pauseWorkflow(), resumeWorkflow(), terminateWorkflow() — Workflow control

Synchronous setState()

State updates are now synchronous with a new validateStateChange() validation hook:

JavaScript

export class MyAgent extends Agent {
  validateStateChange(oldState, newState) {
    // Return false to reject the change
    if (newState.count < 0) return false;
    // Return modified state to transform
    return { ...newState, lastUpdated: Date.now() };
  }
}

TypeScript

export class MyAgent extends Agent<Env, State> {
  validateStateChange(oldState: State, newState: State): State | false {
    // Return false to reject the change
    if (newState.count < 0) return false;
    // Return modified state to transform
    return { ...newState, lastUpdated: Date.now() };
  }
}

scheduleEvery() for recurring tasks

The new scheduleEvery() method enables fixed-interval recurring tasks with built-in overlap prevention:

JavaScript

// Run every 5 minutes
await this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" });

TypeScript

// Run every 5 minutes
await this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" });

Callable system improvements

• Client-side RPC timeout — Set timeouts on callable method invocations
• StreamingResponse.error(message) — Graceful stream error signaling
• getCallableMethods() — Introspection API for discovering callable methods
• Connection close handling — Pending calls are automatically rejected on disconnect

JavaScript

await agent.call("method", [args], {
  timeout: 5000,
  stream: { onChunk, onDone, onError },
});

TypeScript

await agent.call("method", [args], {
  timeout: 5000,
  stream: { onChunk, onDone, onError },
});

Email and routing enhancements

• Secure email reply routing — Email replies are now secured with HMAC-SHA256 signed headers, preventing unauthorized routing of emails to agent instances.
• Routing improvements:
  • basePath option to bypass default URL construction for custom routing
  • Server-sent identity — Agents send name and agent type on connect
  • New onIdentity and onIdentityChange callbacks on the client

JavaScript

const agent = useAgent({
  basePath: "user",
  onIdentity: (name, agentType) => console.log(`Connected to ${name}`),
});

TypeScript

const agent = useAgent({
  basePath: "user",
  onIdentity: (name, agentType) => console.log(`Connected to ${name}`),
});

Upgrade

To update to the latest version:
npm i agents@latest

For the complete Workflows API reference and patterns, see Run Workflows.

Original source Report a problem

Local Uploads

Local Uploads is now available in open beta. Enable it on your R2 bucket to improve upload performance when clients upload data from a different region than your bucket. With Local Uploads enabled, object data is written to storage infrastructure near the client, then asynchronously replicated to your bucket. The object is immediately accessible and remains strongly consistent throughout. Refer to How R2 works for details on how data is written to your bucket.

In our tests, we observed up to 75% reduction in Time to Last Byte (TTLB) for upload requests when Local Uploads is enabled.

This feature is ideal when:

• Your users are globally distributed
• Upload performance and reliability is critical to your application
• You want to optimize write performance without changing your bucket's primary location

To enable Local Uploads on your bucket, find Local Uploads in your bucket settings in the Cloudflare Dashboard, or run:

npx wrangler r2 bucket local-uploads enable <BUCKET_NAME>

Enabling Local Uploads on a bucket is seamless: existing uploads will complete as expected and there’s no interruption to traffic. There is no additional cost to enable Local Uploads. Upload requests incur the standard Class A operation costs same as upload requests made without Local Uploads.

For more information, refer to Local Uploads.

Original source Report a problem