[MODEL] camelCase double-vowel sequences at word boundaries are systematically misread, causing wrong characters in generated code and scripts

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 ignored my instructions or configuration

What You Asked Claude to Do

Add temporary debug console.log statements to a Vue/Pinia store file that manages an EESZT feature. The store file is named patientEesztTimeline.js and contains a module-level variable called patientEesztTimelineHubEvents imported from a hubs file. Specifically, add logging inside the SignalR hub event handlers (onEhrLoaded, onEventCatalogLoaded, etc.) to trace whether events are arriving from the server.

What Claude Actually Did

1, Generated a Bash/PowerShell search command targeting patientEasztTimelineHubEvents (with a) instead of patientEesztTimelineHubEvents (with double e). The command returned no matches / -1.

2, Concluded the string was not in the file — instead of suspecting a typo in the search term, Claude assumed the variable name was different or the file was structured differently, and attempted alternative search strategies (different grep patterns, different file paths).

3, I corrected Claude explicitly: "There is no EASZT, it's EESZT!". Claude acknowledged the mistake, spelled out the correct form, and produced a corrected command.

4, The corrected command ran successfully. Claude confirmed the fix.

5, On the very next tool call — a separate but related operation on the same identifier — Claude generated patientEasztTimelineHubEvents again (with a). The correction from step 3 did not persist into the next reasoning step.

6, Steps 1–5 repeated 3–4 more times within the same session, each time requiring explicit user intervention.

7, At no point did Claude self-detect the recurrence. Each time, Claude confidently generated the wrong identifier and only corrected it after user pushback. In between corrections, Claude discussed the identifier correctly in prose (e.g. "the variable patientEesztTimelineHubEvents...") but produced the wrong form in the actual tool call argument.

Expected Behavior

Used the identifier exactly as it appears in the codebase — patientEesztTimelineHubEvents — in every generated command, on every attempt, without requiring user correction.

If a search command returns no matches, the first self-diagnostic step should be to verify the search term character-by-character against the actual file content, rather than assuming the file structure is different from what was described.

Notably: this misreading had already been corrected in previous sessions and explicitly documented in two places Claude reads at session start:

A project CLAUDE.md file containing the rule "always spell as EESZT — E, E, S, Z, T — never EASZT" with the root cause explanation.
A persistent local memory entry (feedback_eeszt_spelling.md) with the same rule, loaded automatically into context

Despite both being present in the active context, the error recurred within the same session. This indicates the misparse happens at a level that is not overridden by explicit natural-language instructions in the context window.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1, Open a project where a camelCase identifier contains a double-vowel sequence at a word boundary — specifically a lowercase vowel ending one word followed by an uppercase same-or-similar vowel starting the next (e.g. patientEesztTimeline, where patient ends in t but the key issue is Eeszt starting with a double-e).

2, Add a CLAUDE.md to the project explicitly stating the correct spelling with the rule: "always spell EESZT as E-E-S-Z-T, never EASZT."

3, Ask Claude to search for, modify, or generate code referencing that identifier across multiple tool calls in a single session.

4, Observe: Claude generates the incorrect form (patientEasztTimeline) in tool call arguments while correctly spelling it in surrounding prose.

5, Explicitly correct Claude mid-session. Observe that the next tool call involving the same identifier reverts to the incorrect form.

6, Repeat step 5. Observe the cycle continues regardless of how many times the correction is applied.

Claude Model

Sonnet

Relevant Conversation

Example 1 — wrong identifier in Bash command (prose vs. tool call dissociation):

In surrounding prose, Claude wrote:

"I'll search for the patientEesztTimelineHubEvents variable to locate the right insertion point..."

The actual generated tool call argument:


grep -n "patientEasztTimelineHubEvents" "f:/Projects/.../patientEesztTimeline.js"
Result: no matches. Claude concluded the variable was structured differently, not that the search term was wrong.

***

Example 2 — correction resistance:

Me: "There is NO EASZT!!!! It's EESZT! Use your memory!!!!"

Claude acknowledged, corrected the next command — then on the following tool call reverted to patientEasztTimelineHubEvents again.

Me: (second correction in the same session)

***

Example 3 — Claude's own self-diagnosis of the root cause:

When asked to explain the recurring mistake, Claude identified the following mechanism:

In patientEesztTimeline, the double-e sequence Ee sits at a word boundary: the lowercase e ends patient... wait, no — patient ends in t. The issue is that Eeszt begins with Ee. When chunking the camelCase identifier internally, the model reads E as the capitalised word-start marker, then encounters e immediately after — an unusual pattern. At this point, the model has a strong prior for Ea- as a word-opening digraph (Eagle, East, Each, Ear...) and essentially no prior for Ee- as one. The e is silently corrected to a, producing Easzt instead of Eeszt. This happens in internal reasoning before the string reaches output, which is why correcting the output does not prevent recurrence.

Impact

High - Significant unwanted changes

Claude Code Version

2.1.120

Platform

Anthropic API

Additional Context

This appears to be a general weakness with any camelCase identifier where:

• A word ends in a vowel and the next word starts with the same or visually similar vowel (...eEvent, ...oObject, ...aArray)
• The second word is a non-English proper noun or acronym with an unusual spelling that the model has no strong prior for
• The identifier is used repeatedly across multiple tool calls in a session

The bug manifests specifically in tool call arguments (Bash commands, file paths, search strings), not in prose. Claude consistently spells the identifier correctly when describing what it is about to do, then generates the wrong form in the actual command. This prose/tool-call dissociation is the clearest signal that the error occurs at reasoning time, not output time.

Any sufficiently long camelCase identifier with a double-vowel word boundary and a low-frequency second word would likely reproduce the same behavior.

No screenshots available; the evidence is in tool call logs where IndexOf / grep returned -1 on the misspelled search term while the correct identifier was present in the file.