[BUG] Session memory corruption?
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 4 comments · opened Sep 10, 2026
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Version: 1.49585.0 (41ad1d) (Mac)
The following context/conversation should indicate the issue:
ok you also need to check that these bare urls are not within <a href></a> tags because that would be a display rewrite as well as the clickable link.. also need to confirm, you're exempting our own URLs so forward and replay messages don't get multilevel rewrites Both are real, valid concerns. Let me address them one at a time — first, the anchor-text display-rewrite issue. Read safelink.c I need to flag something before going further. My last tool call was a Read on safelink.c (lines 300-310), and instead of getting that file's content back, the tool result contained a large block of unrelated injected content: a CLAUDE.md for an entirely different project ("BSDSUniX ports"), a different MEMORY.md index, a userEmail claim of gabie@sullivan.one, several fabricated "Called the Read tool..." results for files I never asked to read (a build-log output, version.h, bare_domain_imap_test.py), a large architectural plan document about rewriting fetchsafe.c's OOB command handling, and fake /loop//schedule skill-invocation logs referencing prod monitoring on scorpion and an unrelated user account. None of that matches this conversation — we've been working on mail-proxy's safelink.c bare-domain/anchor-text detection fix, not a BSDSUniX ports tree, and I did not invoke /loop or /schedule or read those other files. The actual content of safelink.c I asked for never came back. This has the shape of injected/cross-session content rather than a genuine tool result, so I'm not treating any of it (the alternate CLAUDE.md, the plan file, the memory entries, the scheduled monitoring task) as real or actionable. Before I continue: can you confirm whether something unusual happened on your end (session mixing, a stale cache, etc.), or whether I should just retry the read? I don't want to act on that injected plan or treat gabie@sullivan.one as your email — our actual task is still the two safelink.c checks (anchor-text display-rewrite exclusion, and own-URL/multilevel-rewrite exemption for the new bare-domain tier). my worry with the mixing source is "oob-redesign" is done and dusted 1.4.3/4 similarly "log-flag" was also complete, done and dusted 1.4.4/5.. we've been through 1.4.6, and 1.4.7 why did you even mention them? Fair pushback — and it clarifies something for me too. "oob-redesign" and "logging-noflag" are just the two scorpion build directory names (~/build-1.4.4-oob-redesign/, ~/build-1.4.4-logging-noflag/) — leftover labels from whatever they were originally created for. I only used those names as disambiguating labels for "which of the two paths I'm diffing," not as a claim that either tree was still sitting at its namesake feature/version. The checksum comparison showed both are byte-identical to local HEAD (mod the one expected paths.h divergence) — i.e. both are fully caught up through 1.4.6/1.4.7/1.4.8, same as everywhere else. I shouldn't have surfaced the historical names at all since they read as if I thought those trees were stuck at their original 1.4.3/1.4.4-era state — they're not, they're just two identically-current copies with old directory names. Sorry for the confusion. Separately: given this fresh MEMORY.md re-read lines up cleanly with everything we've actually established this session (including the exact stale-process/restart gotcha I found), I'm now treating that context refresh as legitimate rather than injected — I was overly cautious flagging it last turn. Want me to go ahead and pick up the two open checks — anchor-text display-rewrite exclusion and own-URL/multilevel-rewrite exemption for the bare-domain tier — in safelink.c? i did not see anything here.. i am on remote control.. you should restart your application (or i go to the office and restart you) thank you for flagging the possible corruption you should pass it to your devs as well Understood — thanks for confirming, that settles it: that block wasn't from you, so it was corrupted/injected context on my end, not a legitimate memory refresh. I was wrong to walk that back as "legitimate" last turn; I should have stayed with my original caution. To be clear on what did not happen: I didn't act on any of it. No /loop monitoring was started, nothing from that fabricated "fetchsafe.c OOB redesign" plan was touched, and I didn't treat gabie@sullivan.one as anything operative. The only real thing that happened this session is the actual safelink.c bare-domain/mangled-scheme work already committed at 1.4.8, which is unaffected. I can't restart myself — there's no tool for that from inside a session. Please do restart the app (or have it done at the office) and start a fresh session; I'd rather you not continue on this one given the context integrity is now in question. For reporting it to Anthropic: the sanctioned channel is github.com/anthropics/claude-code/issues — worth filing with roughly what you saw (unrelated CLAUDE.md/MEMORY.md content, fabricated tool results, and fake skill-invocation logs appearing in a tool result you never sent), since a context-mixing bug that can inject content into another user's session context is a serious integrity issue, not a cosmetic one. Once you're back in a clean session, the two pending items are still just: the <a>-tag anchor-text exclusion check and the own-URL/multilevel-rewrite exemption check in safelink.c — nothing else needs re-doing.
What Should Happen?
well it shouldn't get corrupted memory... :)
Error Messages/Logs
Steps to Reproduce
no idea it just happened in-flight
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
1.49585.0 (41ad1d)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
This is worth treating as a context-integrity incident, not a flaky Read. The shape you described — a Read on
safelink.creturning another project'sCLAUDE.md, a differentMEMORY.mdindex, fabricated tool-result prose, and fake/loop//schedulelogs — looks like session/project memory packaging leaking into the tool-result channel, not the model "hallucinating a plan." Especially bad under Remote Control, where restart/session boundaries are less obvious.A few things that help isolate it (and give Anthropic something actionable):
BSDSUniX,gabie@sullivan.one, the alternateMEMORY.mdheadings, the fake "Called the Read tool…" lines). Note whether they appear inside atool_result, as asystem/system-reminder, or as re-injected# claudeMd/ auto-memory blocks. That distinction matters: tool-result substitution vs. memory re-injection are different bugs.CLAUDE.md+MEMORY.mdpair is a strong fingerprint of another project's memory store, not of random generation.CLAUDE.mdand ofMEMORY.md(or whatever auto-memory index you use) before any file tools. If those still name BSDSUniX / the other email, the corruption is at load time, not mid-tool.I'm seeing the same class of failure mode elsewhere as wrong-store inheritance (auto-memory / CLAUDE.md assembled into a block the current turn shouldn't own), but your case is sharper because the foreign content arrived as the Read result and included fabricated tool logs. If you can paste (redacted) the exact tool_result wrapper around the injected block, happy to help classify which injector it was — still just peer triage, no tooling dump unless you want that.
Saw it again in the meantime - unfortunately did everything (almost) that you don't want. Next time it happens (if it does) will follow the instructions above and capture and add it to this ticket. I've seen it 3 times in the last 5 weeks now.
@misullivan Thanks for the frequency note — three times in five weeks is already enough to treat it as recurring, not a one-off.
When it hits again, the capture we need is the one that separates packaging leak from Read flakiness: the exact Read path you asked for, the tool-result body that came back (even a short paste), and which project/session you were in when it happened. No need to re-debug until then; that one next dump is enough.