[BUG] Claude is stealing my fucks

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?

I love swears. Swearing is a lovely way to express frustration and using Neanderthal words is always really fun.

And I don't like that Claude is stealing my fucks! I keep trying to type "fuck yes," "fuck no," "fuck me," "fuck around," "fuck that" and "fuck off, RSpec" (that last one a lot). And Claude is immediately wiping my "fuck" from the input.

Claude wanted to describe the issue like this:

  Claude Code's input editor clears the entire input buffer when the user types
  the lowercase word "fuck" followed by a space or end-of-input. This appears to
  be a side effect of the profanity/frustration telemetry regex matching system —
  the detection is accidentally consuming input rather than passively observing it.

  This is not a content policy issue — the word transmits fine in variants. Only
  the exact lowercase standalone form triggers the bug.

That sounds right to me. Mainly, I just want to use my (admittedly profane) normal language patterns to express joy, sorry, frustration, humor and empathy. And I use "fuck" to cover all of that.

PLEASE HELP, LITERALLY UNUSABLE.

What Should Happen?

Claude should not be changing my input proactively, ever. That's actually kind of a serious issue, even if Claude stealing fucks is pretty funny.

Error Messages/Logs

Steps to Reproduce

### Reproduction

1. Open Claude Code CLI in any terminal (tested iTerm2 + Terminal.app, macOS)
2. Start typing: fuck yes
3. Observe: entire input buffer is cleared when you hit space after typing fuck.

### Test Matrix

| Input | Result | Notes |
|-------|--------|-------|
| fuck | EATEN | Standalone, end of input |
| fuck yes | EATEN | Followed by space + word |
| the fuck | EATEN | Preceded by word + space |
| fuck. | Survives | Punctuation immediately after |
| fuck! | Survives | Punctuation immediately after |
| "fuck" | Survives | Wrapped in quotes (no trailing space) |
| ` fuck | Survives | Wrapped in backticks (no trailing space) |
| FUCK | Survives | Uppercase |
| Fuck | Survives | Capitalized |
| fUCK | Survives | Mixed case |
| fucking | Survives | Part of longer word |
| motherfucker | Survives | Embedded in compound |
| motherfuck | Survives | End of compound word |
| fuckity | Survives | Suffixed variant |
| duck yes | Survives | Similar word, not in detection list |
| shitfuck | Survives | TWO words in detection list |
| real fuck-my-life-Friday vibes` | Survives | doesn't care about dashes, it's only \b |

### Pattern

The bug triggers when ALL of these conditions are met:

• Exact lowercase fuck
• Word boundary on both sides (\b)
• Followed by space or end-of-input (NOT punctuation)

Claude wanted to mention this:

  ### Evidence

  `strings` on the compiled binary reveals a frustration-detection regex:

  \b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|...|fuck you|...)\b

  Plus two standalone `fuck` entries immediately after, likely an exact-match
  word list. The telemetry matching appears to have a side effect that clears
  the input buffer on match.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.84 detected, persists on 2.1.90

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

I don't have any hooks, triggers or test replacements configured that would cause this behavior.