[BUG] Write/MCP tool silently writes [Trimmed input: ~NNN chars] placeholder to disk/API instead of actual content

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When Claude Code passes large content (>~4KB) to a tool parameter (Write, Edit, MCP tools like jira_add_comment), the harness sometimes replaces the entire content with a literal placeholder string:

[Trimmed input: ~15476 chars]

This placeholder is then executed as the tool parameter — written to disk, posted to APIs, etc. The tool reports success. No error is raised. The agent has no signal that corruption occurred.

This is distinct from #895 (where the tool call FAILS with "content is missing"). In this bug, the tool call SUCCEEDS with garbage content.

Observed behavior

• Files written to disk contain literal [Trimmed input: ~15476 chars] instead of intended content
• Jira comments posted as literal [Trimmed input: ~15476 chars]
• Tool returns success — no error surfaced to agent or user
• Agent continues working, unaware the content was corrupted
• Only manual inspection (cat, opening the file, reading the Jira comment) reveals the problem

Observed threshold

• ~4KB per tool parameter: safe
• ~8KB: sometimes works
• ~15KB: always trimmed

The threshold appears to shrink as conversation context grows (more likely to trigger in longer sessions).

Steps to Reproduce

1. Start a session and do enough work to build up context (~50+ tool calls)
2. Attempt to Write a file with >8KB of content in a single call
3. Observe that the file on disk contains [Trimmed input: ~NNN chars] instead of the intended content
4. Note that the Write tool reported success

Alternative reproduction: use any MCP tool (e.g. Jira add_comment) with a large string parameter in a long session.

What Should Happen?

If content would be trimmed, the tool call should fail with an error so the agent can retry with smaller chunks. Silent substitution of a placeholder that looks like valid content is the worst possible failure mode — it's invisible to both agent and user until someone manually inspects the output.

At minimum:

1. Raise an error when content would be trimmed (agent can retry with chunks)
2. Never execute a tool call with placeholder content substituted for actual content

Related Issues

• #895 — canonical "content is missing" issue (tool call FAILS). Our bug is the inverse: tool call SUCCEEDS with corrupted content.
• #45436 — excellent root cause analysis showing 8K output token ceiling and stop_reason=max_tokens truncation. Closed as dupe of #895, but that analysis applies here too.
• #27896 — comment from @DeanLa suggests "Bedrock dropping tool calls with a payload >4kb" which matches the ~4KB threshold observed here.

Root cause hypothesis

The harness has a truncation marker system (confirmed by changelog: "Fixed tool error truncation marker showing a negative count for surrogate-pair strings"). In some code path — possibly when stop_reason=max_tokens truncates a tool_use block, or when a display-layer truncation marker leaks into the execution path — the placeholder string gets substituted into the actual tool parameter before execution rather than causing a tool call failure.

Claude Model

Opus

Claude Code Version

v2.1.112

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

iTerm2 + zsh