CRITICAL 1: ensureObjectArgs (renamed from safeParseToolArgs) in
run-handler.ts now throws on non-object parsed results so the catch
block fires TOOL_ARGUMENT_PARSE_FAILED structured errors.
CRITICAL 2: partialJSONParse return type reverted from
Record<string,unknown> to unknown — callers handle the type.
IMPORTANT 3: safeParseToolArgs consolidated into shared/utils.ts and
exported. Agent/index.ts imports from @copilotkitnext/shared. V1 keeps
a local copy with a comment noting it mirrors the shared version.
IMPORTANT 4: All non-object fallback sites now emit console.warn with
consistent [CopilotKit] prefix format.
IMPORTANT 5: Removed console.warn from getPartialArguments catch block
(incomplete JSON is expected during streaming). Warning is now only in
the try-block non-object guard.
TEST 6: Added run-handler-ensureObjectArgs.test.ts covering valid
object, string, number, array, null, boolean, and undefined inputs.
TEST 7: Added conversion.test.ts for v1 safeParseToolArgs covering
valid object, string, number, array, malformed JSON, null, boolean,
and empty string inputs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Guard partialJSONParse, both agui-to-gql converters, and
run-handler.ts against LLMs returning non-object JSON (strings,
arrays, numbers, booleans, null) as tool arguments. Adds
safeParseToolArgs helper to run-handler.ts and tests for all sites.
Rename ensureObjectArgs to safeParseToolArgs in v2/agent and v1/runtime,
folding JSON.parse into the guard so malformed JSON (e.g. "{broken") is
caught instead of throwing an unhandled SyntaxError up the call stack.
Add console.warn on parse failure in all three locations (v2/agent,
v1/runtime, v1/runtime-client-gql) so malformed tool arguments are
visible in logs rather than silently swallowed.
Update the v2/agent unparseable-JSON test to expect {} instead of throw.
When LLMs return non-object values (e.g. empty string) as tool call
arguments, the parsed result is stored in conversation history. On
subsequent requests, providers like Anthropic reject the non-dictionary
tool_use input with a 400 error, making the conversation permanently
broken.
Fixed in 4 locations across v1 and v2:
- v1 runtime conversion.ts: validate parsed arguments
- v1 client conversion.ts: validate partial arguments
- v2 core run-handler.ts: validate both specific and wildcard tool args
- v2 agent index.ts: validate tool call input conversion
All locations now ensure parsed args are a plain object, falling back to
{} for non-object values.
Fixes#3300
## Description
Fixes#3208
When using a LangGraph agent with an orchestrator node that routes to
terminal nodes,
the orchestrator typically uses `copilotkit_customize_config(config,
emit_messages=False)`
to suppress its internal LLM output (e.g., routing decisions like
"left_intent") from
being streamed to the frontend.
However, the `dispatchEvent` override in the CopilotKit `LangGraphAgent`
was only
suppressing the events from reaching the `verifyEvents` pipeline — it
was **not**
cleaning up the `messagesInProcess` tracking state. This caused a stale
message record
from the orchestrator to persist and leak into subsequent nodes that
have
`emit_messages=True`, ultimately triggering a `verifyEvents` error:
```
Cannot send 'TEXT_MESSAGE_END' event: No active text message found with ID '...'.
A 'TEXT_MESSAGE_START' event must be sent first.
```
### Root cause (step by step)
1. Orchestrator calls LLM with `emit_messages=False` → metadata has
`copilotkit:emit-messages: false`
2. Orchestrator's LLM streams text → `handleSingleEvent` (in
`@ag-ui/langgraph`) calls
`setMessageInProgress()` unconditionally, then calls `dispatchEvent()`
for `TEXT_MESSAGE_START`
3. CopilotKit's `dispatchEvent` suppresses the event (returns `false`),
but the message
record is already tracked in `messagesInProcess`
4. When `TEXT_MESSAGE_END` is later suppressed, it also returns `false`
— so
`messagesInProcess` is **never cleared** (the cleanup is gated on `if
(resolved)`)
5. The next node (e.g., `left_node`) starts with `emit_messages=True`.
Its first LLM chunk
(often empty content) sees the **stale** `messagesInProcess` record and
determines
`isMessageEndEvent = true`
6. It dispatches `TEXT_MESSAGE_END` with the orchestrator's message ID,
but since the
raw event now carries `copilotkit:emit-messages: true`, CopilotKit does
**not** suppress it
7. `verifyEvents` sees a `TEXT_MESSAGE_END` for a message ID that never
had a
`TEXT_MESSAGE_START` → throws the error
### Fix
When `dispatchEvent` suppresses message events due to
`copilotkit:emit-messages === false`,
it now also nullifies the corresponding
`messagesInProcess[activeRun.id]` entry. This
prevents stale records from leaking across node boundaries.
## Type of Change
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
## How Has This Been Tested?
Tested manually with a LangGraph agent containing:
- An **orchestrator node** using `copilotkit_customize_config(config,
emit_messages=False)` that classifies user intent and routes via
`Command(goto=...)` to one of two terminal subgraphs
- Two **terminal nodes** (`left_node`, `right_node`) using
`copilotkit_customize_config(config, emit_messages=True)` that call an
LLM and stream the response
Before the fix: every message sent through CopilotSidebar triggered the
`TEXT_MESSAGE_END` error and `INCOMPLETE_STREAM`.
After the fix: messages flow correctly — the orchestrator's internal
output is suppressed and the terminal node's response streams to the
frontend as expected.
Covers the fix for stale messagesInProcess cleanup, plus general
filtering behavior for both copilotkit:emit-messages and
copilotkit:emit-tool-calls metadata.
The v1 CopilotRuntime always set afterRequestMiddleware on the v2 runtime,
causing parseSSEResponse to attempt reading the cloned SSE stream body even
when no user hooks existed. This results in "Failed to read SSE response
body in afterRequestMiddleware" warnings. Only register the handler when
the user actually provided afterRequestMiddleware or middleware.onAfterRequest.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fixes#2903
## The Bug
Azure OpenAI users get `AI_LoadAPIKeyError: OpenAI API key is missing`
despite passing a properly configured `OpenAI` instance to
`OpenAIAdapter`, exactly as shown in the docs.
**Root cause**: `CopilotRuntime.handleServiceAdapter()` discards the
adapter's configured OpenAI instance and constructs a plain string
`"openai/gpt-4o"` to pass to `BuiltInAgent`. The agent's
`resolveModel()` then creates a *brand new* OpenAI provider using only
`OPENAI_API_KEY`, losing all Azure configuration (baseURL, api-key
header, api-version query param).
The V1 adapter's `process()` method — which correctly uses the custom
OpenAI instance — is dead code. It's never called. Only `.provider` and
`.model` strings are extracted.
```
User configures Azure OpenAI instance →
OpenAIAdapter stores it →
CopilotRuntime extracts only "openai"/"gpt-4o" strings →
BuiltInAgent.resolveModel("openai/gpt-4o") →
createOpenAI({ apiKey: OPENAI_API_KEY }) →
💥 API key missing / wrong endpoint
```
## Workaround
Until this is merged, users can bypass the broken adapter entirely by
using `BuiltInAgent` directly with the Vercel AI SDK Azure provider:
```typescript
import { createAzure } from "@ai-sdk/azure";
import { CopilotRuntime, copilotRuntimeNodeHttpEndpoint } from "@copilotkit/runtime";
import { BuiltInAgent } from "@copilotkitnext/agent";
const azure = createAzure({
resourceName: process.env.AZURE_RESOURCE_NAME,
apiKey: process.env.AZURE_API_KEY,
});
const runtime = new CopilotRuntime({
agents: {
default: new BuiltInAgent({
model: azure("your-deployment-name"),
}),
},
});
// Then use copilotRuntimeNodeHttpEndpoint as usual — no serviceAdapter needed
```
This works because `BuiltInAgent` already accepts `LanguageModel`
instances and `resolveModel()` passes them straight through.
## The Fix
Add an optional `getLanguageModel()` method to `CopilotServiceAdapter`.
Adapters that accept custom SDK instances (OpenAI, Anthropic, Groq) now
implement this to produce a pre-configured Vercel AI SDK `LanguageModel`
that carries the full provider configuration. `CopilotRuntime` prefers
this over the string format when creating `BuiltInAgent`.
**Backward compatible**: `getLanguageModel()` is optional on the
interface, so existing custom adapters continue to work unchanged.
| File | Change |
|------|--------|
| `service-adapter.ts` | Add optional `getLanguageModel()` to
`CopilotServiceAdapter` interface |
| `openai-adapter.ts` | Implement `getLanguageModel()` using
`createOpenAI` with the configured instance's `baseURL`/`apiKey` |
| `anthropic-adapter.ts` | Implement `getLanguageModel()` using
`createAnthropic` |
| `groq-adapter.ts` | Implement `getLanguageModel()` using
`createOpenAI` (Groq is OpenAI-compatible) |
| `copilot-runtime.ts` | Prefer `serviceAdapter.getLanguageModel()` over
string model when creating `BuiltInAgent` |
| `package.json` | Add `ai`, `@ai-sdk/openai`, `@ai-sdk/anthropic`
dependencies |
## Test plan
- [x] V2 agent tests pass (101/101)
- [x] V1 runtime build succeeds with no type errors
- [x] V1 runtime tests: same pass/fail as `main` (pre-existing failures
unrelated to this change)
- [ ] Manual: configure Azure OpenAI via `OpenAIAdapter` without
`OPENAI_API_KEY` — should work without `AI_LoadAPIKeyError`
- [ ] Manual: standard OpenAI via `OpenAIAdapter` with `OPENAI_API_KEY`
— should continue working
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Max Korp