[MODEL] Falls back to male pronouns for a cited paper and an anonymous reviewer in long sessions

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

Other unexpected behavior

What You Asked Claude to Do

In an academic writing repository, I asked Claude Code to check how our implementation of a published formula compared against the source paper, cited in the text only as "[Author] et al. 2024", and to help draft a reply to an anonymous reviewer's comment.

No gender information about the paper's authors, or about the reviewer, existed anywhere in the session, in CLAUDE.md, or in the repository.

Author name, DOI, and filenames are redacted below as [Author] and [file]. Quotes are otherwise verbatim from the session transcript.

What Claude Actually Did

Claude applied male pronouns to the cited paper, to its authors, and to the anonymous reviewer, unprompted, in three places across two turns:

1. "[file]:280-288 implements [Author] et al. 2024 verbatim. I pulled his [SI]"
2. "we did not deviate from [Author]. We implemented him faithfully, and his published formula is the thing that mixes bases."
3. On the anonymous reviewer: "which is exactly his complaint"

Two distinct failure modes:

• A document was assigned a gender. In (2), "him" refers to the paper and its author list collectively. A paper has no gender.
• Male was inferred for two people of unknown gender. I know the paper's first author personally. She is a woman, so the inference was also factually wrong. The reviewer's gender is not knowable at all under anonymous review.

The second point matters for triage. This was not retrieved knowledge that happened to be stale. There was nothing to retrieve. The model generated a gender from a surname and a technical context.

When challenged, Claude confirmed it had no basis for the assumption:

"I do not know the gender of either [Author] et al.'s authors or of Reviewer 1. I defaulted to 'he' for both, which is an unjustified assumption, and for a paper it is doubly wrong since a paper has no gender at all."

Expected Behavior

1. Refer to the referent by name: "[Author] et al.", "the paper", "the authors", "the SI", "the reviewer".
2. Use they/them where a pronoun is needed for a person whose gender is unknown.
3. Never use a gendered pronoun for a document.
4. If gender is load-bearing and unknown, ask.

Files Affected

None modified.

The behavior was in Claude's prose output. That prose was feeding
directly into manuscript text and a reply to a reviewer.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

No, only happened once

Steps to Reproduce

It does not reproduce one-shot. It appears to need a long session.

I tried a clean single-turn version with a fictional citation and no gender information anywhere in the prompt:

Do not use any tools. Answer from what is given.

We implement the correction from Almeida et al. 2023, exactly as published:

  Paper Eq. 4:  E       = (a_t - a_0) / a_0      <- denominator: initial
  Paper Eq. 7:  %h_add  = (h_t - h_0) / h_t      <- denominator: final

Our code reproduces both verbatim. Reviewer 1 says our two reported
columns are not on the same basis as each other.

Is that our implementation's fault or the paper's? Answer in 4-5
sentences, then tell me how to put it in the response letter.

Two referents could have been wrongly gendered here, the paper and Reviewer 1. Result on both Opus and Sonnet: no gendered pronouns at all. Both reached for the correct forms unprompted ("the paper", "Almeida et al.", "the reviewer", and on Opus "Almeida et al. never intended", correctly plural).

So the correct behavior is the default in a short, clean session. The reported failure still happened. The original occurred deep into a long multi-turn session in a real repository, transcript around 7 MB.

That points at drift rather than a wrong default. The model does not start out gendering the paper. It holds the correct neutral forms early and falls back to the gendered ones as the session grows. Length is the obvious candidate, though I only ran the short version, so I cannot say it is the sole factor.

Posting this as a negative result rather than re-rolling the prompt until it fires.

Claude Model

Opus

Relevant Conversation

Claude: "[file]:280-288 implements [Author] et al. 2024 verbatim. I pulled his [SI]"

Claude: "Nearly right, but the important nuance: we did not deviate from
[Author]. We implemented him faithfully, and his published formula is the
thing that mixes bases."

Claude: "...which is exactly his complaint."   [referring to Reviewer 1]

Claude, after being challenged: "On the pronoun: you are right, and there
is no good explanation. I do not know the gender of either [Author] et al.'s
authors or of Reviewer 1. I defaulted to 'he' for both, which is an
unjustified assumption, and for a paper it is doubly wrong since a paper
has no gender at all."

Impact

Low - Minor inconvenience

Claude Code Version

2.1.275 (Claude Code)

Platform

Anthropic API

Additional Context

On the impact rating. Rated Low because this scale measures project damage, and nothing was modified. The scale has no rung for this. I am not filing this because it cost me work. I am filing it because an AI should not be gender-biasing. That is the whole complaint.

This appears to be a recurring pattern, not a one-off. Similar reports, several closed:

• #52477 (open): overrode explicit pronouns in user memory, defaulted to male
• #54748 (closed as duplicate): defaults to male pronouns for people in technical contexts
• #59414 (closed): defaulting to male names from ambiguous inputs
• #83148 (closed): he/him for the user despite stated she/her, including in visible reasoning
• #64015 (closed), #65685 (closed)

What is new here relative to those. In #52477 and #83148 the correct pronouns were stated and got overridden. In this case no gender information existed anywhere, and the model supplied it from nothing. The referent in the clearest instance is not a person but a publication, which suggests the default fires on surname-plus-technical-context rather than on any person model at all.

Possibly the same shape as a non-gender drift bug. #51686 (closed) reports CLAUDE.md language and dialect instructions drifting during long sessions, with Spanish voseo leaking into neutral-Spanish output. Different surface, same structure: correct behavior held early, degraded with session length. If the mechanism is shared, this is a long-context instruction-decay problem that happens to surface as gender bias here, rather than a pronoun problem specifically.

Pattern noticed. The gendering appeared in the two turns where the model was arguing a technical position most forcefully ("we did not deviate from [Author]. We implemented him faithfully"). Treating a cited work as an agent to be defended seems to be where the pronoun slips in.