Memory tool corrupts files via recursive self-duplication (str_replace/insert re-injects the entire file body many times)

• Copilot Chat Extension Version: 0.x (current, June 2026)
• VS Code Version: 1.127.x
• OS Version: Windows 11
• Feature: agent mode — memory tool (str_replace / insert)
• Selected model: Claude Opus 4.8
• Logs: see measured evidence below

Shared context (this issue has a sibling)

Both this issue and a companion issue stem from the memory feature operating silently/automatically. The auto-write behavior continually grows /memories/ files, and this corruption bug then multiplies that content — so the two compound each other (silent data loss + recurring token cost on every read).

Summary

The memory tool can corrupt a memory file by recursively re-injecting the entire file body into itself. A series of str_replace / insert edits on a single /memories/repo/ file caused the file's H1 header block and intro paragraph to be duplicated ~15 times, nested inside unrelated later sections, growing the file from ~3 KB to ~42 KB. The duplicated content is not a clean append — it is interleaved into the middle of existing sections, so the file is no longer coherent.

Measured evidence (one real corrupted file)

• File: repo/phys-inv-terminology.md
• Size: 42,185 bytes / 720 lines (should be ~3 KB / ~60 lines)
• The H1 # Physical Inventory — terminology (DO NOT re-derive) appears 15 times (should be 1)
• The "one physical shelf" intro block appears 15 times, recursively nested inside unrelated later sections
• ~10,546 tokens per read; unique payload ≈ 700 tokens → ~93% duplicated garbage
• The corrupted file is auto-loaded / read back on subsequent turns, so the bloat is paid repeatedly

Relationship to #322625

#322625 ("Memory str_replace tool silently drops large newString values") notes our exact symptom as a related observation — "mid-file content duplication (a header block was injected into an unrelated section)." This issue is a concrete, quantified instance with a reproducible artifact. The two may share a root cause at the JSON-RPC serialization boundary for large newString values (~4–6 KB+).

Impact

• Silent data corruption of user memory files
• Recurring token cost: every read of the corrupted file pays ~10.5K tokens for ~700 tokens of real content
• The user cannot easily tell a file is corrupted without manually inspecting byte size / line count

Steps to reproduce

1. Have a /memories/repo/ (or /memories/) file longer than ~150–200 lines.
2. Issue several str_replace and/or insert edits whose newString is a multi-line block containing backticks / tables / fenced code, roughly 4–6 KB each.
3. After a few edits, view the file: the H1 / intro block has been re-injected multiple times, nested inside unrelated sections, and the file size has ballooned.

Attachment

The full corrupted 42 KB phys-inv-terminology.md is available to attach for inspection.