Bug: spawn/task tool mis-encodes non-ASCII prompt into lone UTF-16 surrogates -> API 400 "invalid high surrogate" on spawned session's first request

Bug report — spawn_task mis-encodes non-ASCII prompt into lone UTF-16 surrogates → API 400 on spawned session's first request

Summary

When spawning a session via the task/spawn tool (task chips → spawned sub-session/worktree
with an initial prompt), non-ASCII characters in the initial prompt (accented Latin letters
á/é/í/ó/ú/ñ, em-dashes —, arrows →) are mis-encoded into lone UTF-16 surrogates
during serialization. A lone surrogate is not UTF-8 encodable, so the spawned session's
first model request fails with:

API Error 400: invalid high surrogate in string

This kills the first turn of the freshly spawned session.

Environment

• OS: Windows 11 Pro (10.0.26200), PowerShell 5.1 host
• Claude Code: 2.1.113
• Repo locale: Spanish (prompts routinely contain accented characters)

Steps to reproduce

1. From an interactive session, spawn a task/sub-session whose initial prompt contains

non-ASCII characters, e.g. a Spanish sentence: Ejecutá PR2: revisá el deploy → fase 1.

1. Let the spawned session start and issue its first request.

Expected

The non-ASCII prompt is encoded as valid UTF-8 and the first request succeeds.

Actual

The first request fails with API Error 400: invalid high surrogate in string.
Inspecting the spawned session's JSONL transcript, the user-prompt record starts with the
corruption — e.g. Ejecut?PR2, where the á of "Ejecutá" became a lone high surrogate
(serialized as an invalid \uD8XX with no following low surrogate).

Evidence / root cause

• The corruption happens inside the spawn path during serialization — the prompt text

composed by the caller is valid UTF-8; the lone surrogate appears only after spawn_task
writes it to the spawned session's transcript.

• A lone surrogate (UTF-16 code unit in U+D800–U+DBFF or U+DC00–U+DFFF with no pair) cannot

be UTF-8 encoded; when it reaches the request body the API rejects the whole request.

Impact

• Any spawned session whose prompt contains non-ASCII (common for non-English users) can fail

on its first turn.

• Hooks cannot mitigate reliably: the corruption is downstream of the caller and the JSONL

sanitizers (Stop/PostToolUse) run after the first request. It is undocumented whether a
UserPromptSubmit hook rewriting the JSONL affects the first in-memory request.

Workaround

Write spawn/chip prompts in ASCII (fold accents/em-dashes/arrows before passing them to the
spawn tool).

Suggested fix

Ensure the spawn path serializes the initial prompt as valid UTF-8 (or rejects/sanitizes lone
surrogates) before persisting it to the spawned session's transcript / building the first request.

Privacy note

The JSONL transcript can contain sensitive content — redact before attaching, or attach only the
minimal corrupted prompt record.