[Bug] Persistent errors after /compact and /clear commands

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/76161
2. https://github.com/anthropics/claude-code/issues/77158

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate of #77158 (or #76161). Different failure class — please don't auto-close.

My actual error, which my issue body failed to capture (the auto-populated Errors block came through empty as [], which is why this looks matchable to anything):

API Error: Output blocked by content filtering policy
API Error: 400 Output blocked by content filtering policy

This is an API-side output block — the model's response is rejected server-side. No tool call is denied, and no permission boundary is cited.

Why it isn't #77158:

1. #77158 is a misfire of the auto-mode safety classifier under --permission-mode auto. I run bypassPermissions, which skips the permission classifier entirely. I checked all 718 of my local session transcripts: permission modes recorded are bypassPermissions (3,229), default (521), acceptEdits (57) — zero auto. The component that malfunctions in #77158 is not in my execution path.

1. I grepped every transcript for the #77158 denial signature — "boundary has not been lifted", "Do NOT use Read, Bash, Grep", "auto mode classifier", "waste your only turn". Zero organic hits. (The only matches were transcripts where I'd literally fetched issue #77158 itself.)

1. #77158 = a tool call denied with a quoted reason. Mine = a completion blocked by a content filter. Different layer, different mechanism.

Why it isn't #76161: that's scoped-skill discovery breaking after compaction. Mine produces no skill errors.

Additional detail on mine: the error recurs across multiple terminals and persists after both /compact and /clear — so it isn't driven by accumulated conversation context. That suggests something re-loaded into every fresh session (auto-loaded CLAUDE.md / memory files, or my project content) is tripping the output filter. Happy to provide sanitized transcript excerpts or the specific context that reproduces it.

Environment: Claude Code 2.1.209, darwin, Apple_Terminal.

Narrowed to a deterministic repro. The trigger is content-specific, not context-specific.

Repro: ask Claude Code to write a file whose contents are <option> tags for the 50 U.S. states + DC (postal abbreviation as value, state name as label). The turn dies with:

API Error: Output blocked by content filtering policy

Control: the same request for a structurally identical file — 51 <option> tags of industrial valve types, same shape, same length, same tool — succeeds every time. Only the content differs.

This also explains the "persists after /compact and /clear" symptom in my original report: the trigger is the task, not accumulated context. Each fresh session immediately re-attempts the same file and is blocked again, which made it look like a compaction bug. It isn't — which further confirms this is not a duplicate of #77158.

Impact: subagents hit this too and are killed mid-run (Agent terminated early due to an API error: API Error: Output blocked by content filtering policy) with no indication of the cause. Across 5 sessions over 2 days the file was never successfully written. A legitimate and extremely common web-form snippet appears to be unemittable, and the failure surfaces as an opaque API error rather than anything actionable.

Workaround for anyone else hitting this: generate the list programmatically from a data source (CSV/JSON) via a script, so the state names never appear in model output.

Independent data point, different content domain, different OS, different version — and it supports your "content-specific trigger" finding, with one refinement.

Setup: long-running session used for personal English study. Photos of pages from a paper grammar textbook (Cambridge, English Grammar in Use) are attached, and the text is transcribed into the user's own spreadsheet, one unit at a time. This worked for units 28–31 across several weeks in the same session.

Two incidents, one week apart, both on the transcription turn:

| date | CLI | what happened |
|---|---|---|
| 2026-07-27 | 2.1.218 | Unit 31 (have to / must) — write of the full unit text as one batch → API Error: Output blocked by content filtering policy. Retried, blocked again. |
| 2026-08-03 | 2.1.220 | Unit 32 (must / mustn't / needn't), 2 page photos in context → blocked on the turn that would transcribe the page. |

The part that may be useful to you: on 2026-07-27 there was a workaround. The exact same text went through when it was split into three smaller writes (17 + 13 + 10 rows) instead of one. Same session, same content, same tool, minutes apart — one large write blocked, three smaller writes all succeeded. That is consistent with your valve-vs-states control: content matters, but so does how much of it lands in a single turn.

One refinement to "content-specific, not context-specific". On 2026-08-03 the session did not recover, and the blocks were not limited to turns that would emit the flagged text:

03:32:44  turn OK    (Bash tool call, Drive lookup)
03:33:20  400        (would have transcribed the page)
03:39:22  turn OK    (Bash tool call, checking sheet is empty)
03:39:49  400        (would have written the text)
03:41:01  400        reply to "what the hell is this:" + pasted error log
03:42:01  400        reply to "is the classifier blocking you?"
03:42:16  /model → switched to a different model
03:43:23  400        reply to "тут?" ("you there?")

The last one is a one-word "you there?". No plausible completion of that turn contains textbook text, and switching models changed nothing. So in this session the flagged material sitting in the input context was sufficient to block, independent of what the output would have been. Your repro shows the content trigger; this shows it can also poison a session going forward. Note I did not test /clear here — the session was abandoned — so I can't say whether that would have cleared it.

Auto-compact fired at 03:32:19 and worked correctly (798k → ~400k tokens); it is not implicated. Context at the time of the failures was ~400k tokens, containing several dozen photographed textbook pages accumulated over prior weeks.

Request IDs

2026-08-03 (CLI 2.1.220, 400 status):
req_011Cdf7Pdqw9CBN351qizopF, req_011Cdf7th5DTJaZAE6Yf4uNz, req_011Cdf7xnTGyhGf56GUKidFM, req_011Cdf83FyboortDbrkop461, req_011Cdf87iCYWTpCT7tvJqYSi

2026-07-27 (CLI 2.1.218):
req_011CdRus9Vhaom5RTLcAqrMc, req_011CdRvX95CnJZeranMNVHpM

Environment: Linux, direct Anthropic API (no ANTHROPIC_BASE_URL, no Bedrock/Vertex, no env overrides in settings.json), Opus 4.8 at time of failure, then Opus 5 — same result.

What I can't confirm: the 400 carries no detail about what was flagged (the transcript records only apiErrorStatus: 400, "error": "unknown", and the message string). Both incidents landing on verbatim textbook reproduction is a correlation across two data points, not something the API stated. Worth flagging regardless: the user is transcribing their own paper textbook into their own private spreadsheet for language study, and there is no way from the CLI to see what tripped the filter or to remove it from context.

Related, both closed without resolution: #69721 (same pattern — page-by-page OCR correction of an academic textbook, ~80 pages fine, then a hard block) and #21880 (mid-session blocks causing work loss; a commenter there reports the same "every single prompt following" behaviour).