bug(streaming): JSON.parse crashes on invalid escape sequences in model output

[bilal-azam]

Bug Report

Description

When Claude outputs a string containing certain escape sequences that are valid in some contexts but not strict JSON (e.g., \d, \p, \s as regex literals inside a JSON string), the streaming parser crashes with an unhandled SyntaxError. This surfaces as an unhandled rejection that crashes the entire application.

Reproduction

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

// Ask Claude to produce output containing regex-like content
const stream = await client.messages.stream({
  model: 'claude-sonnet-4-6',
  max_tokens: 500,
  messages: [{
    role: 'user',
    content: 'Return a JSON object with a "pattern" field containing the regex \\d+\\.\\d+ as a string value. Return ONLY the JSON.'
  }],
});

// This may crash: SyntaxError: Invalid escape sequence
const message = await stream.finalMessage();

Expected Behavior

The SDK should gracefully handle malformed JSON from the model, either by:

1. Attempting lenient JSON parsing (JSON5 / repair strategies)
2. Returning the raw string with a warning
3. Emitting a recoverable error event instead of throwing

Actual Behavior

SyntaxError: Invalid or unexpected token
at JSON.parse ()
at MessageStream.parse (src/lib/MessageStream.ts:XXX)
...

The error is unhandled and crashes the Node.js process.

Proposed Fix

Wrap all JSON.parse calls in the streaming pipeline with a recovery strategy:

function safeParseJSON<T>(text: string): T | null {
  try {
    return JSON.parse(text) as T;
  } catch {
    // Attempt to repair common model output issues
    const repaired = repairInvalidEscapes(text);
    try {
      return JSON.parse(repaired) as T;
    } catch {
      return null; // Emit warning, don't crash
    }
  }
}

Environment

• @anthropic-ai/sdk version: latest
• Node.js version: 20.x
• Trigger: Models asked to produce JSON containing regex patterns, Windows paths, LaTeX

I'm happy to submit a PR. 🙏

[MukundaKatta]

Hi — looked at this before filing code. A few questions before I'd submit a PR:

1. Reproduction — has this been observed in the wild, or is it speculative? The issue uses "may crash." I ran the exact example script in the reproduction against @anthropic-ai/sdk latest and got a well-formed JSON response ("pattern": "\\d+\\.\\d+" — the backslashes are properly escaped on the wire). Do you have an actual stack trace from a real session, or a recorded SSE event stream where the parse fails? If it's the latter, attaching the raw event bytes (curl -N + some TEE, or DEBUG=anthropic-sdk:*) would make it actionable.

2. Server-side contract. The Anthropic API controls the SSE wire format — if the server emits unescaped \d inside a JSON string, that's a server bug. Wrapping JSON.parse with a recovery strategy in the SDK would mask server regressions rather than surface them. Would a failed-fast approach with a clearer error message be acceptable instead of the lenient-parse approach?

3. Scope. There are ~10 JSON.parse sites in the SDK streaming pipeline (src/core/streaming.ts:54, :92, :159; src/internal/decoders/jsonl.ts:19, :24; plus partial-json-parser/parser.ts:262 which is the existing partial-parse fallback). If the goal is to wrap them, that's a 10-site coordinated change — worth a design decision first.

My take: if you have a real repro, I'd write the PR as "log the raw event and clearer error message" rather than "silently recover with a repaired-JSON parser" — but happy to go whichever direction the maintainers prefer.

Can you share a real failing trace or confirm the direction you'd like?

[MukundaKatta]

Hi — looked at this before filing code. A few questions before I'd submit a PR:

1. Reproduction — has this been observed in the wild, or is it speculative? The issue uses "may crash." I ran the exact example script in the reproduction against @anthropic-ai/sdk latest and got a well-formed JSON response ("pattern": "\\d+\\.\\d+" — the backslashes are properly escaped on the wire). Do you have an actual stack trace from a real session, or a recorded SSE event stream where the parse fails? If it's the latter, attaching the raw event bytes (curl -N + some TEE, or DEBUG=anthropic-sdk:*) would make it actionable.

2. Server-side contract. The Anthropic API controls the SSE wire format — if the server emits unescaped \d inside a JSON string, that's a server bug. Wrapping JSON.parse with a recovery strategy in the SDK would mask server regressions rather than surface them. Would a failed-fast approach with a clearer error message be acceptable instead of the lenient-parse approach?

3. Scope. There are ~10 JSON.parse sites in the SDK streaming pipeline (src/core/streaming.ts:54, :92, :159; src/internal/decoders/jsonl.ts:19, :24; plus partial-json-parser/parser.ts:262 which is the existing partial-parse fallback). If the goal is to wrap them, that's a 10-site coordinated change — worth a design decision first.

My take: if you have a real repro, I'd write the PR as "log the raw event and clearer error message" rather than "silently recover with a repaired-JSON parser" — but happy to go whichever direction the maintainers prefer.

Can you share a real failing trace or confirm the direction you'd like?