[Opus 4.7] CJK character corruption in TodoWrite content field (recurs after correction)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Long-running Chinese-language coding session implementing a debugger
feature. As part of routine progress tracking, Claude was updating
its internal task list via the TodoWrite tool. No special instruction
about output format.

What Claude Actually Did

The TodoWrite tool received content field values containing
nonsensical rare-character bigrams in Chinese, while the parallel
activeForm field (describing the same task in the same JSON object)
was correct. The corruption recurred after the user pointed it out
and Claude attempted to rewrite.

Occurrence #1 — message msg_016cxzrU1Z3TFZgcg9T7EQui
request req_011CaEB7fDo3iUiUkFQJcVw3
cache_read ~127k tokens

"content": "controller 加 auto-step 状态 + 犳徨压后发下一步"
"activeForm": "扩展 controller: auto-step 状态 + cycle 计数 + kHex 后调度 step-in"

Occurrence #2 — message msg_019y857a7R7ZEwtcDCPfjtfy
request req_011CaEBLtXMh7uV8KDWoynF8
cache_read ~147k tokens
(rewrite attempt after user flagged #1)

"content": "controller 加 auto-step 状态 + 接压后发下一步"
"activeForm": "扩展 controller: auto-step 状态 + cycle 计数 + kHex 后调度 step-in"

"犳" (U+72B3) is an extremely rare character; "犳徨" and "接压" are
non-words in Chinese.

Expected Behavior

The content field should contain a meaningful Chinese phrase
matching the semantic intent expressed in the activeForm field,
e.g. "controller 加 auto-step 状态 + kHex 到达后调度下一步".

Files Affected

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

No minimal repro available. Both incidents occurred in a single
long-running session at high cache_read token counts (127k / 147k)
in 1M-context mode, after one /compact summarization.

Claude Model

Opus

Relevant Conversation

Two specific assistant messages:
- msg_016cxzrU1Z3TFZgcg9T7EQui (req_011CaEB7fDo3iUiUkFQJcVw3)
- msg_019y857a7R7ZEwtcDCPfjtfy (req_011CaEBLtXMh7uV8KDWoynF8)

Full local jsonl transcript exists; can share privately on request.
Public posting withheld due to proprietary code in the session.

Impact

Low - Minor inconvenience

Claude Code Version

2.1.114 (VSCode native extension)

Platform

Anthropic API

Additional Context

• Exact model ID: claude-opus-4-7 (Opus 4.7, 1M context mode)
• Working language: Chinese (zh-CN)
• Session state: ~150k tokens, after one /compact
• Mixed content in session: Chinese + English + C++ code + JSON

Notable patterns:

1. Corruption confined to TodoWrite.input.content. Parallel

activeForm field, main reply prose, and code/comments in the same
turn were all clean Chinese.

1. Recurrence after explicit correction (different garbled bigram,

same position) suggests not single-shot sampling noise.

1. Both incidents at high cache_read in 1M-context mode.

Possible directions (speculative):

• Are short JSON string fields in nested tool-call arguments sampled

under different constraints than free-form reply text?

• Does sampling under high cache_read in 1M-context mode show

degraded CJK character selection?

Originally emailed to support (Conversation ID: 215473984260816); redirected here per their reply.