False-positive content filter blocks benign UI animation prompts in Claude Code

Summary

The Claude Code content filter is repeatedly blocking entirely benign UI / animation prompts in mid-session. I'm iterating on a SwiftUI Canvas-based waveform component (seaweed-blade leaves that bend toward an audio playhead cursor) for my Tide iOS app. Two prompts in the same session have now been blocked even though the surrounding conversation, the open files, and the active code edits are unambiguously about graphics + Bezier curves + spring physics on a SwiftUI view.

Blocked prompt (verbatim)

ok the physics are better. now we just need to make it respond in a more realistic way. make it so the ends of the stuff attaches to the cursor as it passes. and it should pull them until they reach a point and then release. right now the ends are sticking out all weird i can't explain. do a full pass from teh root to tip of the wave leaf. and then make it so they flow passively as well. just subtle while it's waitinf for more recordings.

Every term here is unambiguously about a UI/animation feature:

• "ends" / "tip" = the apex of each rendered blade
• "cursor" = the audio playhead position on a waveform timeline
• "attaches" / "pull" / "release" = sticky-cursor spring physics — catch, stretch, snap free
• "root to tip" = blade base to apex on a Bezier curve
• "wave leaf" = the visual leaf-shape my renderer draws per waveform column
• "flow passively" = ambient Perlin-noise sway when idle

Claude itself confirmed twice (after each block) that there is nothing remotely policy-relevant in the prompt — it's standard SwiftUI / game-physics vocabulary in unambiguous context. The assistant was actively editing WakeField.swift and BrushWaveformView.swift (a SwiftUI Canvas renderer) immediately before and after these blocks.

A second prompt later in the same session was also blocked, presumably on similar lexical grounds.

Likely trigger

Combinatorial misfire on common animation verbs ("attach", "pull", "release", "ends", "stick") co-occurring with informal phrasing ("the stuff", "make it so"). In any sane semantic read the surrounding context is clearly UI work.

Impact

• I have to censor my own product-feature vocabulary mid-conversation
• The classifier is asymmetric — I get blocked but receive no signal about what class of content tripped it, so any rephrase is a guess
• Erodes trust in Claude Code as a daily driver for creative / animation / graphics work where this vocabulary is unavoidable

Asks

1. Investigate the rule firing here. The semantic context is overwhelming evidence against a real violation.
2. Surface a hint about which class of content the filter believed it caught, so users can rephrase deliberately instead of guessing.
3. Calibrate against benign-vocabulary contexts — a session with *.swift files open, the assistant actively writing addCurve / Path / spring-physics code, and the user using animation verbs, should not trip a content filter.

Environment

• Claude Code CLI (latest as of 2026-05-22)
• macOS 26.x, Apple Silicon
• Project: SwiftUI iOS app (Tide); files in scope Sources/Models/WakeField.swift, Sources/Views/BrushWaveformView.swift