TextDecoder.decode() fails on Node.js 22

[MarcSigot3B]

When using the SDK on AWS Lambda with Node.js 22, the following error occurs:

Calling the invoke API action failed with this message: Failed to execute 'decode' on 'TextDecoder': parameter 1 is not of type 'ArrayBuffer'

Node.js version: 22
Runtime: AWS Lambda
SDK version: 0.71.2
Package: @anthropic-ai/sdk

Workaround : downgrade the Lambda runtime to Node.js 20.

[jeanpierrecarvalho]

I’m hitting this as well on AWS Lambda with Node.js 22. I took a quick look and this seems to be in the streaming decode path. The SDK ends up calling TextDecoder.decode() with a Uint8Array view/subarray, and it looks like some Node.js 22 Lambda environments are stricter about that than Node.js 20. A small fallback to decode from a standalone ArrayBuffer should make this robust without changing behavior in the normal case.

[jeanpierrecarvalho]

I took a deeper look and built a closer repro around the SDK stream path on real Lambda nodejs22.x.

The issue seems to be in the UTF-8 decode step while the SDK is parsing streamed chunks. The code ends up calling TextDecoder.decode() on Uint8Array views/subarrays, and in stricter environments that can fail with:

Failed to execute 'decode' on 'TextDecoder': parameter 1 is not of type 'ArrayBuffer'

I tested it in two ways:

• a lower-level repro around the stream decoding path
• a closer end-to-end repro through client.messages.stream() with a mocked SSE response, running on real AWS Lambda

On the messages.stream() repro specifically:

• before the change, the whole stream fails on the strict decoder path with that error
• after changing decodeUTF8() to retry with bytes.slice().buffer on TypeError, the same repro completes and returns the final message normally

So the fix is basically:

• try decoder.decode(bytes) first
• if that throws this specific shape of TypeError, retry with a standalone ArrayBuffer

That keeps the normal path unchanged and only falls back when the runtime is picky about the input type.

I also added local coverage at both levels:

• a focused decodeUTF8() test
• a higher-level messages.stream() regression test

One nuance: on the Lambda function I used, process.version came back as v22.22.0, and I couldn’t get a tiny direct TextDecoder.decode(Uint8Array view) probe to fail natively in isolation there. So I can’t say I reproduced the exact raw runtime behavior outside the SDK path on current Lambda.

But the SDK-level failure mode is definitely reproducible under the stricter decoder behavior, and the fallback fixes that cleanly.

I will open a PR with the fix and some tests if that would help.