CodeExecutionToolResultBlock.ToParam() drops stdout/stderr/return_code via omitzero (same class as #242, #317)

[goalsoft]

Description

CodeExecutionToolResultBlock.ToParam() produces a malformed CodeExecutionToolResultBlockParam when the API returns a successful code execution result. The stdout, stderr, and return_code fields are dropped during re-serialization (when they contain zero values), causing a 400 from the API on the next agentic-loop iteration.

Error from API:

messages.21.content.1.code_execution_tool_result.content.RequestCodeExecutionToolResultError.type: Input should be 'code_execution_tool_result_error'

(The misleading error name RequestCodeExecutionToolResultError is because with all result fields dropped, the API falls back to parsing the now-empty content against the error-variant schema and fails on its required type discriminator.)

Root cause

In messageutil.go L345-364:

func (r CodeExecutionToolResultBlock) ToParam() CodeExecutionToolResultBlockParam {
    var p CodeExecutionToolResultBlockParam
    p.Type = r.Type
    p.ToolUseID = r.ToolUseID
    if r.Content.JSON.ErrorCode.Valid() {
        p.Content.OfRequestCodeExecutionToolResultError = &CodeExecutionToolResultErrorParam{
            ErrorCode: r.Content.ErrorCode,
        }
    } else {
        p.Content.OfRequestCodeExecutionResultBlock = &CodeExecutionResultBlockParam{
            ReturnCode: r.Content.ReturnCode,
            Stderr:     r.Content.Stderr,
            Stdout:     r.Content.Stdout,
        }
        // ...
    }
    return p
}

CodeExecutionResultBlockParam fields are tagged json:"...,omitzero". When a code execution returns zero/empty values (very common: successful runs often have ReturnCode=0, empty Stderr, or empty Stdout), omitzero drops the fields entirely. The API then rejects the request because the content object becomes {"type": "code_execution_result"} only, which doesn't match any valid variant shape.

Reproduction

1. Multi-turn conversation with claude-opus-4-7 and extended thinking (adaptive mode with display: omitted)
2. Trigger built-in web_search that leads Claude to use code_execution for analysis
3. On the next turn (replaying the assistant message containing the code_execution_tool_result block), API rejects with the error above.

Reliably reproducible in production when Call Face-style code-review agents loop through 20+ tool calls with thinking enabled.

Same class of bug

• ToolSearchToolResultBlock.ToParam() drops required error_code field via omitzero #317 — ToolSearchToolResultBlock.ToParam() drops error_code
• ToParam() Method Doesn't Handle WebSearchToolResultBlock #242 — WebSearchToolResultBlock.ToParam() same pattern

All three tools share the same pattern: ToParam() unconditionally assigns fields that have omitzero tags, and zero values silently disappear. Suggest auditing all *ToolResultBlock.ToParam() methods for this pattern.

Workaround (adapted from #317)

import "github.com/anthropics/anthropic-sdk-go/packages/param"

content := msg.ToParam().Content
for i, block := range msg.Content {
    switch block.AsAny().(type) {
    case anthropic.CodeExecutionToolResultBlock,
         anthropic.WebSearchToolResultBlock,
         anthropic.ToolSearchToolResultBlock:
        if i < len(content) {
            content[i] = param.Override[anthropic.ContentBlockParamUnion](block.RawJSON())
        }
    }
}

Environment

• SDK version: v1.37.0 (bug present, confirmed in multi-turn loops)
• Go version: 1.24
• Model: claude-opus-4-7 (triggers this more often due to server-tool + extended thinking integration)

Suggestion

Drop the omitzero tags on required fields in *ResultBlockParam structs, or explicitly set api:"required" and have ToParam() skip the omitzero behavior. A cleaner long-term fix would be for all ToParam() methods on server tool result blocks to use raw JSON passthrough internally (similar to the workaround above) — since the response shape is already server-produced and server-validated.

/cc #242 #317 — same bug class, systematic issue in ToParam() pattern

[goalsoft]

Update / Correction — the original diagnosis was partly wrong. Posting the corrected story in case it helps others.

What the repro actually shows

Running a minimal ToParam round-trip on SDK v1.37.0:

var blockUnion anthropic.ContentBlockUnion
_ = json.Unmarshal([]byte(`{
  "type": "code_execution_tool_result",
  "tool_use_id": "srvtoolu_xyz",
  "content": {
    "type": "code_execution_result",
    "stdout": "hello world", "stderr": "", "return_code": 0, "content": []
  }
}`), &blockUnion)

paramUnion := blockUnion.ToParam()
paramJSON, _ := json.Marshal(paramUnion)                   // first marshal
var recovered anthropic.ContentBlockParamUnion
_ = json.Unmarshal(paramJSON, &recovered)                  // re-parse
finalJSON, _ := json.Marshal(recovered)                    // second marshal

Output:

Round-trip: {"content":{"return_code":0,"stderr":"","stdout":"hello world","type":"code_execution_result"},"tool_use_id":"srvtoolu_xyz","type":"code_execution_tool_result"}
Final:      {"content":{"type":"code_execution_result"},"tool_use_id":"srvtoolu_xyz","type":"code_execution_tool_result"}

So:

• ToParam() + first json.Marshal is correct — stdout/stderr/return_code are there.
• Fields only disappear on Unmarshal(paramJSON, &ContentBlockParamUnion) → Marshal — i.e. the union UnmarshalJSON path doesn't populate the nested content variant's fields, so the next marshal emits an empty object.

My title and root-cause section blamed ToParam() + omitzero, which is not accurate — CodeExecutionResultBlockParam.Stdout/Stderr/ReturnCode are plain json:"..." tags without omitzero, and they serialize correctly on the first pass. The real bug is in the union unmarshal, not in ToParam().

What actually caused my production 400

I need to be honest about this one — the 400 I hit in production after adopting the param.Override workaround was my own bug, not the SDK:

// my broken workaround
blocks = append(blocks, param.Override[anthropic.ContentBlockParamUnion](string(rawJSON)))

param.Override stashes the value in metadata and MarshalWithExtras/MarshalUnion later call shimjson.Marshal(ovr). When ovr is a Go string, that produces a JSON string literal ("…escaped…") — not a pass-through of the bytes. So the assistant message ended up with content[0] = a JSON string, and the API rejected with:

messages.7.content.0: Input should be a valid dictionary or object to extract fields from

The fix is the one already shown in the SDK's own code (e.g. Base64PDFSource.ToParam() does exactly this):

// corrected workaround
blocks = append(blocks, param.Override[anthropic.ContentBlockParamUnion](
    json.RawMessage(block.RawJSON()),
))

With json.RawMessage, shimjson.Marshal pass-through writes the raw bytes. The example in my original comment (param.Override[…](block.RawJSON())) has the same issue — RawJSON() returns string, so it needs to be wrapped. Sorry about that.

Does anything SDK-side still need fixing?

Yes — the union UnmarshalJSON → Marshal roundtrip still loses the nested fields (see the repro output above). That will bite anyone who persists request params to disk / a queue and later restores them. The ToParam() path by itself is fine for the common "call API → serialize → send" pattern.

A minimal fix would be to populate the nested content-union variants in ContentBlockParamUnion.UnmarshalJSON (or skip that layer entirely and keep the raw bytes around for re-marshalling, the same way param.Override works).

Updating the title to match the corrected root cause might also help future readers land on the right SDK behavior.

[Aaravanand00]

Hi @goalsoft
I took a closer look at this and found that the issue wasn’t in ToParam(), but in how the unions were being unmarshaled.

For code_execution_tool_result, the nested code_execution_result wasn’t getting properly routed based on the type discriminator. Because of that, fields like stdout, stderr, and return_code were getting dropped during a round-trip (Unmarshal → Marshal).

I added explicit handling for all variants in CodeExecutionToolResultBlockParamContentUnion.UnmarshalJSON so the correct struct gets populated, which fixes the field loss.

I also added tests covering :-

1. Full round-trip (Unmarshal → Marshal → Unmarshal → Marshal)
2. Zero-value cases (empty stdout/stderr, return_code = 0)

Ran everything locally with :- go test -v -run TestIssue322
and both tests are passing.