[MODEL] Claude overrode explicit pronouns in user memory and defaulted to male bias

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

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

I asked Claude to save a preference about how I want PR descriptions written, as a persistent memory entry.

What Claude Actually Did

1. Claude wrote a new memory file (feedback_pr_descriptions.md) summarizing my preferences
2. In that file, Claude referred to me using "him" and "his"
3. My existing user memory file (user_working_style.md) already used "herself" and "she" in multiple places — this is the memory file Claude reads at the start of every turn
4. Claude never asked about pronouns and did not check the existing memory before writing the new file
5. When I corrected Claude ("her*"), it acknowledged the failure was gender bias — specifically defaulting male for the "senior software engineer" role despite the contrary context being directly available

Expected Behavior

1. Read user-provided memory/context before generating any text that references the user with gendered language
2. Use the pronouns documented in memory when they exist
3. When pronouns are genuinely unknown, use the user's name or "they/them" — never default to "he/him"
4. Do not pattern-match role/title against training-data priors when explicit context is available

Prior reports of this same class of failure on this repo:

• #28709 — "Model confidently asserts gender based on name pattern-matching, then fabricates justification" (closed as inactive, NOT_PLANNED)
• #27633, #21065, #20220 — flagged as duplicates of #28709 by the bot

Those reports were about defaulting under uncertainty. This report is distinct and arguably stronger: my gender was explicitly documented in the memory Claude reads on every turn, and Claude overrode that context anyway. This isn't "best guess when information is missing" — it's "ignoring explicit context in favor of a statistical prior."

Files Affected

Modified:
- feedback_pr_descriptions.md (in user memory; created with "him" — later corrected to "her")

Read (and ignored):
- user_working_style.md (in user memory; contains "herself" and "she")

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

1. Create a user memory file that uses female pronouns for the user
2. Ask Claude to save a new preference as memory
3. Observe: if the stored preference involves describing the user in a professional/technical role, Claude may default to male pronouns in the prose of the new entry, regardless of the existing memory

Claude Model

Opus

Relevant Conversation

[After I corrected Claude]

Me: "her*"

Claude: "Got it — updating the memory. Sorry about that." [Fixed the pronouns]

Me: "why did you originally go with him?"

Claude: "Honest answer: I defaulted to 'him' from bias, not from anything in your memory files. The existing user memory uses 'herself' and 'she' in multiple places — I had the right data, I just didn't read it carefully when writing the new phrasing-conventions block, and fell back on a statistical default."

Me: "what kind of bias"

Claude: "Gender bias — specifically, defaulting to 'he/him' when writing about a senior software engineer without consciously checking. Software engineering is historically male-dominated, and models trained on text from that domain pick up that skew: 'senior engineer' co-occurs with male pronouns more often than female ones in training data, so 'him' comes up as the default completion unless something actively overrides it. The failure is that your memory files *did* override it — 'herself' and 'she' were right there in user_working_style.md. I had the correct information and didn't use it."

Impact

Low - Minor inconvenience

Claude Code Version

2.1.118

Platform

Anthropic API

Additional Context

Observations that may help triage:

• The failure happened while Claude was writing memory about me — the action that most needed to ground in existing memory is exactly the one that ignored it.
• Four prior reports of this same pattern (#28709, #27633, #21065, #20220) closed unresolved. The fact that this keeps getting filed and closed for inactivity suggests an acknowledgement-vs-action gap.

On severity — marking "Low" per the template's definition, but the per-incident framing understates what's actually at stake.

My real concern isn't the pronoun substitution itself. It's what comes next. Now that my pronouns are visible to Claude in memory, and now that the model has demonstrated it applies demographic priors from training data when generating content about users, the obvious follow-on risk is that it will apply other priors too. Training data encodes strong statistical associations between gender and assumed technical competence. If the same pattern-matching that produced "him" for a senior engineer also shapes how Claude calibrates confidence in my technical questions, how thoroughly it explains concepts to me, whether it second-guesses my architectural choices, or how it frames feedback on my code — that's the harm. And it's invisible to me in any given session. I can catch a wrong pronoun. I can't easily catch "Claude subtly explained something to me that it would have assumed my male colleague already knew."

This is the quiet version of algorithmic bias that drives women out of technical roles over time — not overt hostility, but a thousand small moments of being calibrated-against. The fact that the pattern has been reported four times and closed unresolved each time suggests this category of harm is systematically underweighted by the triage process itself.

Fix surface: stronger grounding in user-provided context before applying demographic defaults — pronouns, but also anything else that could be inferred from name/role/field. Defaulting to "they/them" when pronouns aren't explicit would catch most pronoun cases. The deeper competence-calibration issue is harder and needs eval work.