Consistent parsing error when updating file that contains `<name>Whatever</name>`

Description of the issue:

This is happening with 2 files generated by Claude:

• An XML file that contains the tag <name>Whatever</name>.
• A JS file that contains a regex that targets the <name>Whatever</name> tag in the XML file (myXMLFile.match(/<name>([^<]+)<\/name>/);).

In both instances, when it first writes the file, it works fine.

However, when it attempts to update anything in the files, Claude reads <name>...</name> as <n>...</name>, detects it as an issue, and gets stuck in a loop trying to fix it.

• Reads it as <n>.
• Tries to replace <n> with <name>.
• Doesn't find <n> because it doesn't exist, the replacement fails.
• Reads the file again to check if the issue is fixed.
• Reads it again as <n>.
• Tries to fix it...

Claude's summary of the issue:

The problem I'm experiencing is a display/parsing discrepancy with XML tags in file content. When viewing certain files, I see XML tags incorrectly (e.g., <n> instead of <name>) but when I try to edit them, the system can't find the text to replace because what I'm seeing doesn't match the actual file content.

This creates a confusing situation where: 1. I see <n> in the displayed file content. 2. When I try to edit it to <name>, the edit fails because the text to replace isn't found. 3. The actual file may already have <name> correctly.

I asked what commands is it using for the task.

When reading files, I use: 1. View tool: Used with file_path parameter to read content 2. Bash with cat: Sometimes I use this to view file contents

When editing files, I use: 1. Edit tool: Requires file_path, old_string, and new_string 2. Replace tool: Completely replaces file content 3. Bash with sed: For targeted string replacements

The discrepancy occurs because:

When I read with View or cat, some XML tags are displayed incorrectly (e.g., <n> instead of <name>). But when I try to use Edit to modify this content, it fails because the actual file content has <name> instead of the <n> I'm seeing.

The tools are accessing the same filesystem, but there seems to be an inconsistency in how the content is parsed or displayed when read versus how it's matched when edited.

This mismatch between what I see and what I can modify causes confusion and failed edit operations.

Environment info:
Ubuntu 22.04.5 LTS on WSL.