Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@cloudflare/think@0.13.0

Minor Changes

• #1907 38bf87a Thanks @cjol! - feat(think): add channelSpeakerLabel option to MessengerDefinition for configurable channel speaker prefixing

  Channel (non-DM) messages and action events are prefixed with the speaker label
  so the model can attribute multi-user traffic; direct messages never get a
  prefix. Previously action events were labelled even in DMs — they now follow the
  same channel-only rule as regular messages.

• #1921 7e0c069 Thanks @cjol! - Add ChatOptions.metadata — a per-turn, recovery-safe metadata carrier.

  Server-side callers of chat() / chatWithMessengerContext() can now attach immutable per-turn metadata (e.g. "which authenticated principal initiated this turn"). It is stamped onto the turn's user message alongside channel (as metadata.turnMetadata) so a recovered/continued turn re-resolves it from durable history, and is readable turn-scoped via the new Think.activeTurnMetadata getter.

  The trust model mirrors the channel stamp: the reserved metadata keys channel and turnMetadata are now stripped from client-supplied messages at intake, so a client can never forge server-written turn context (this also closes the prior gap where a client message could carry a forged metadata.channel). This lets messenger/RPC entry points carry correct multi-user identity without either mutable agent-wide state (a last-writer-wins race) or the submission path (which loses incremental streaming).

Patch Changes

• #1920 0235fc9 Thanks @cjol! - Rewrite the bot's own unresolved self-mention in messenger events to its readable handle before the model sees it.

  When a user @-mentions a Think messenger bot, the triggering message leads with the bot's own mention. Adapters resolve every other user's mention to @DisplayName but leave the bot's own as a raw user-id token (for example, Slack's @U0BD9EYL52S), which small models can misread as a third party the sender was trying to reach. Think now rewrites that surviving self-mention to @<userName> (the bot handle already required on every messenger) in defaultChatSdkEvent, reconstructing the @handle the sender originally typed.

  Adds the exported resolveSelfMention helper. Rewriting only applies when the adapter exposes a botUserId, so handle-based adapters (for example, Telegram) are unaffected. No new configuration is required.

agents@0.17.4

Patch Changes

• #1902 a9d78c0 Thanks @mattzcarey! - Always apply the Worker-safe CfWorkerJsonSchemaValidator to MCP client connections by default.

  MCPClientConnection now owns the default (merged in its constructor), so every construction path uses the Worker-safe validator unless the caller supplies their own — including the RPC addMcpServer(name, namespace) path via MCPClientManager.connect(), which previously skipped it. Without the default, the MCP SDK fell back to its AJV validator when a server exposed tools with outputSchema; AJV compiles schemas with new Function, which Workers disallows, failing discovery with "Code generation from strings disallowed for this context".

  connect() now builds connections through createConnection() instead of duplicating construction, so the two paths can no longer drift. Caller-supplied client.jsonSchemaValidator overrides are respected on the live connection; because validator instances cannot survive JSON serialization, they are no longer persisted, and a previously persisted, serialization-degraded validator is ignored on restore — after hibernation the connection falls back to the Worker-safe default instead of failing discovery.

• #1903 3ba6a78 Thanks @mattzcarey! - MCP client: url-mode elicitation support with a real elicitation handler

  • Agents can now respond to server-initiated elicitation/create requests by
    calling this.mcp.configureElicitationHandlers({ form, url }), typically in
    onStart(). The advertised modes are persisted with each MCP server, so
    connections restored after Durable Object hibernation re-advertise them at
    the handshake and the handlers re-attach when onStart runs.
  • Connections advertise elicitation modes based on what can actually be
    handled: they advertise exactly the modes with configured handlers at the
    initialize handshake; without handlers they advertise no elicitation
    capability. An explicit
    client.capabilities.elicitation (e.g. via addMcpServer) always wins,
    is persisted with the server options, and survives hibernation — it is no
    longer clobbered by a hardcoded value.

• #1925 762998d Thanks @mattzcarey! - MCP client: consume the persisted capability seed at first use instead of at restore-time read

  The capability stamp persisted on each MCP server row (used to re-advertise elicitation modes at the handshake after Durable Object hibernation) was read-and-cleared when the connection object was created, before any connection attempt. Wakes that never reached a handshake burned it: a restore that parked on a pending OAuth flow, or a wake interrupted between restore and onStart re-stamping the rows, left the next wake's connections negotiating without the elicitation capability until some later reconnect.

  The stamp is now read without clearing and only cleared once a seeded handshake actually completes in a session that has not configured handlers, preserving the one-successful-restore semantics: after the seed is used in a completed handshake it no longer re-advertises stale modes, and any configureElicitationHandlers call still re-stamps every row. Sessions with handlers configured own their row stamps, so a handshake there (e.g. re-adding a server under a stable id) keeps the fresh stamp in place for the next wake.

• #1910 9e1b733 Thanks @mattzcarey! - MCP client: advertise no elicitation capability when no handler is configured

  Connections without an elicitation handler previously advertised form-mode
  elicitation while rejecting every elicitation request that arrived, so
  spec-compliant servers chose elicitation over their fallback flows and the
  tool call failed mid-flight. Connections now advertise the elicitation
  capability only when it can be handled: form mode, URL mode, or both, based on
  handlers configured via this.mcp.configureElicitationHandlers({ form, url }).
  Connections without handlers advertise no elicitation capability, letting
  servers fall back gracefully.

  An explicit client.capabilities.elicitation declaration remains authoritative.
  Only advertise modes your Agent can handle.

• #1869 f274903 Thanks @mattzcarey! - Fix addMcpServer() reporting ready for an HTTP MCP connection that was restored while OAuth is still in progress.

  For an existing AUTHENTICATING connection, addMcpServer() now prefers the live authorization URL, otherwise returns a persisted absolute HTTP(S) authorization URL. If neither is available, it reconnects the existing connection without re-registering it: a new authorization URL is returned and persisted, a connected result is discovered before returning ready, and failed or incomplete OAuth results throw instead of falling through to ready.

@cloudflare/codemode@0.4.3

Patch Changes

• #1904 88f7f69 Thanks @mattzcarey! - Echo the durable tool-call log on the proxy tool output. ProxyToolOutput now carries an optional calls field (the execution's ToolLogEntry[]) on completed, paused and error outcomes, so UIs can render an audit trail of every connector call and step — name, args, result, approval requirement and state — without a separate executions() round trip.

@cloudflare/voice@0.3.4

Patch Changes

• #1909 63491bd Thanks @cjol! - Honor the configured sample rate for raw pcm16 audio payloads.

  Adds a sampleRate option to VoiceAgentOptions (default 16000) that is declared in the server audio_config message. VoiceClient reads it (exposed via a new sampleRate getter) and constructs AudioBuffer instances at that rate for raw pcm16 playback, so providers with a native rate other than 16 kHz (e.g. 24 kHz Gemini TTS) play at the correct speed. Falls back to 16 kHz when the server omits the field.

• #1891 d1cc317 Thanks @korinne! - Add transcriber readiness so voice agents wait for streaming STT startup before entering listening state or running call-start hooks.

@cloudflare/agent-think@0.0.1

Patch Changes

• Updated dependencies [a9d78c0, 3ba6a78, 762998d, 0235fc9, 9e1b733, f274903, 38bf87a, 7e0c069]:
  • agents@0.17.4
  • @cloudflare/think@0.13.0

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.