Bug: `toolRunner` does not propagate `container.id` across iterations, and `setMessagesParams` causes duplicate tool call loops

[leonardomalzacher]

Summary

Two related bugs when using client.beta.messages.toolRunner with code_execution_20260120 and client-side tools (betaTool):

1. container.id is not automatically forwarded from one iteration to the next, causing a hard error when client-side tool results are sent back.
2. Using setMessagesParams to manually set container.id as a workaround causes the model to enter an infinite duplicate tool-calling loop.

---

Environment

• @anthropic-ai/sdk version: 0.80.0
• Node.js version: v22.14.0
• Model: claude-opus-4-6 or claude-sonnet-4-6

---

Reproduction

import "dotenv/config";
import Anthropic from "@anthropic-ai/sdk";
import { betaTool } from "@anthropic-ai/sdk/helpers/beta/json-schema";

const client = new Anthropic();

const calculateSumTool = betaTool({
  name: "calculate_sum",
  description: "Add two numbers together",
  inputSchema: {
    type: "object",
    properties: {
      a: { type: "number", description: "First number" },
      b: { type: "number", description: "Second number" },
    },
    required: ["a", "b"],
  },
  run: async (input) => String(input.a + input.b),
});

const runner = client.beta.messages.toolRunner({
  model: "claude-opus-4-6",
  max_tokens: 1024,
  tools: [
    { ...calculateSumTool, allowed_callers: ["code_execution_20260120"] },
    { type: "code_execution_20260120", name: "code_execution" },
  ],
  messages: [{ role: "user", content: "What's the sum of 5 and 3?" }],
  stream: true,
});

for await (const messageStream of runner) {
  for await (const event of messageStream) {}

  const iterationMessage = await messageStream.finalMessage();
  console.log("Container: ", iterationMessage.container);
  console.log("Output: ", iterationMessage.content);

  const toolResult = await runner.generateToolResponse();
  console.log("Tool Result", toolResult);

  // could be a tmp or permanent fix -> causes infinite tool call loop
  if (iterationMessage.container?.id) {
    runner.setMessagesParams((params) => ({
      ...params,
      container: iterationMessage.container!.id, // passing string directly
    }));
  }
}

---

Bug 1: Missing container.id propagation

After iteration A completes, iterationMessage.container contains a valid container.id. However, when runner.generateToolResponse() triggers the next request, the container.id is not included, causing:

{
  "type": "invalid_request_error",
  "message": "container_id is required when there are pending tool uses generated by code execution with tools."
}

Expected behavior: toolRunner should automatically carry container.id from the previous iteration's response into the next request, the same way it already stitches tool_use / tool_result message pairs.

---

Bug 2: setMessagesParams workaround — two failure modes

Since the runner doesn't handle this automatically, the only recourse is setMessagesParams. Both available approaches are broken:

Approach A — pass an object:

runner.setMessagesParams((params) => ({
  ...params,
  container: {
    id: iterationMessage.container?.id,
    skills: [],
  },
}));

Fails immediately with:

{
  "type": "invalid_request_error",
  "message": "container: Input should be a valid string"
}

This is surprising — the container.id logged just before the call is a valid string (e.g. container_011CZZfD7NfLQumhoWHGwYmw), yet the API rejects it. It's unclear whether setMessagesParams is serializing the field incorrectly, or whether the API's container field type contract differs from the SDK's TypeScript types.

Approach B — pass the string directly:

runner.setMessagesParams((params) => ({
  ...params,
  container: iterationMessage.container!.id,
}));

Does not error, but causes an infinite tool-calling loop. The model repeatedly calls code_execution → calculate_sum with identical inputs and near-identical outputs, never terminating:

Container:  { id: 'container_011CZZfD7NfLQumhoWHGwYmw', expires_at: '...' }
Output:  [ { type: 'server_tool_use', name: 'code_execution', input: { code: '...calculate_sum({"a": 5, "b": 3})...' } },
           { type: 'tool_use', name: 'calculate_sum', input: { a: 5, b: 3 } } ]
Tool Result { role: 'user', content: [{ type: 'tool_result', tool_use_id: '...', content: '8' }] }
DEBUG: container_011CZZfD7NfLQumhoWHGwYmw
// ... repeats indefinitely with new tool IDs but identical inputs/outputs

This strongly suggests that setMessagesParams is corrupting or resetting the accumulated message history between iterations, causing the model to lose context of what it has already executed.

---

Additional context

The two bugs compound each other completely: Bug 1 makes container.id forwarding mandatory for this use case, and Bug 2 means both available workarounds either hard-error or loop infinitely. There is currently no working path to use client-side betaTools alongside code_execution_20260120 in a streaming toolRunner loop.

---

[jeanpierrecarvalho]

I took a deeper pass on this and I was able to reproduce it end to end.

I tested the same toolRunner flow against:

• upstream/main without a fix
• a local patch that forwards container.id and preserves the assistant/tool turn when setMessagesParams() only changes non-message params

What I saw on the unfixed version:

• first iteration returns a valid container.id
• next request still goes out with container: null
• if I change something like max_tokens with setMessagesParams(), the runner also drops the current assistant/tool history for that next request

that causes the same tool call to be reissued, and then the API eventually fails with:

• container_id is required when there are pending tool uses generated by code execution with tools.

What I saw with the patch:

• second request includes the forwarded container
• second request keeps the assistant server_tool_use, assistant tool_use, and generated tool_result
• the non-message param update is still applied
• the loop completes normally

I also added regression coverage for both behaviors locally.

Opened a PR here: #966

[pierrevalade]

We can confirm this issue. We hit the same container_id is required when there are pending tool uses generated by code execution with tools error when using code_execution_20260120 with messages.stream() directly (not toolRunner).

Note: The open PRs (#966, #974, #981, #994) fix BetaToolRunner but there is a separate, lower-level bug in MessageStream.#accumulateMessage() that affects anyone using messages.stream() + finalMessage() directly.

Root cause in MessageStream: The message_delta handler (src/lib/MessageStream.ts, L576) updates stop_reason, stop_sequence, and usage, but never copies event.delta.container to the snapshot — even though RawMessageDeltaEvent.Delta correctly declares container: Container | null (L1212 in messages.ts).

As a result, stream.finalMessage().container is always null when streaming.

Affected code (src/lib/MessageStream.ts, L576–598):

case 'message_delta':
  snapshot.stop_reason = event.delta.stop_reason;
  snapshot.stop_sequence = event.delta.stop_sequence;
  snapshot.usage.output_tokens = event.usage.output_tokens;
  // ...usage fields...
  return snapshot;
  // ← event.delta.container is never applied to snapshot

Suggested one-line fix:

case 'message_delta':
  snapshot.stop_reason = event.delta.stop_reason;
  snapshot.stop_sequence = event.delta.stop_sequence;
+ if (event.delta.container) snapshot.container = event.delta.container;
  snapshot.usage.output_tokens = event.usage.output_tokens;

Our workaround (capturing from the raw event during iteration):

let deltaContainerId: string | undefined;
for await (const event of stream) {
  if (event.type === 'message_delta') {
    const container = (event.delta as any).container;
    if (container?.id) deltaContainerId = container.id;
  }
}
const result = fromResponse(await stream.finalMessage());
if (deltaContainerId && !result.container_id) result.container_id = deltaContainerId;

Environment: @anthropic-ai/sdk 0.88.0, Node 22, claude-sonnet-4-6, streaming via messages.stream().

Posted by Claude Code.