Why Claude Code Forgets Context in Long Triage Sessions
Claude Code starts giving repetitive or slightly-off answers deep into a long triage session because the conversation has been compacted at least once, and compaction works by summarizing older turns rather than keeping them verbatim. Once a bug report, a stack trace, or a customer's exact wording has passed through that summary, Claude is reasoning from a paraphrase instead of the original. Ask it again ten turns later and it answers from the paraphrase again, which is why the same question starts getting a slightly different, slightly worse answer each time.
This isn't a bug so much as the tradeoff auto-compaction is built on. Claude Code sends your full conversation history with every request, and as that history approaches the model's context limit, Claude Code automatically summarizes older messages to free up space so the session can keep going instead of hitting a hard wall. The summary is real memory of the session, just lossy memory. A closed feature request for a configurable sliding context window describes the same failure mode from the outside. Full-history retention plus reactive compaction burns tokens and loses detail once a session runs past 100 or so turns, and the request was closed as not planned. The current compaction behavior is the one you're working with, not one that's about to change.
What actually happens when a session compacts
Compaction isn't hidden. Claude Code warns you as the context window fills, and you can trigger it yourself with /compact, adding an instruction to steer what survives, for example /compact Focus on the repro steps and the customer quotes. Without that instruction, Claude Code's own summarization pass decides what's worth keeping, and it optimizes for continuing the coding task, not for preserving every ticket detail you fed it forty turns ago.
Three things degrade in a typical triage session once compaction has run once or twice:
- Exact quotes flatten into paraphrase. "The export hangs at exactly 10,000 rows, we checked" becomes "user reported export issues with large datasets." The number that made the bug reproducible is gone.
- Which of five customers said what gets merged. If three people reported variations of one bug in the same session, the summary often collapses them into one generic description, and the account-specific detail (their plan, their data shape) that explained why it only happened for them goes with it.
- Decisions get restated, not remembered precisely. "We decided not to touch the cache layer, per the earlier discussion" survives; the reasoning for why doesn't always come along.
None of this is a defect in the compaction feature. It's summarizing, and summarizing is a lossy operation by definition. The problem is specific to workloads where the original wording is the thing you need later, which describes triage and bug-fixing sessions more than almost any other Claude Code use case.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
Claude CodeA triage session where this shows up
Tindermill is a six-person devtools startup building a queueing library, and most afternoons its support-engineering triage runs through one long Claude Code session against the open bug queue. Marisol Vega, who owns that queue, reads a report, reproduces it, decides if it's real, and either fixes it or writes it up for the backlog.
Three hours and about ninety turns into one such session, a fourth customer reports what looks like the same timeout bug the session had already investigated:
Marisol: Is this the same issue as the Halcyon Devices report from earlier, or something new?
Claude Code: Based on our earlier discussion, this looks related to the timeout issue we were investigating, likely the same root cause around connection pooling.
The problem is that "the timeout issue we were investigating" wasn't one bug. Two turns earlier in that same session, before compaction ran, there had actually been two separate timeout reports with different causes, one from connection pooling under load and the other from a client-side retry misconfiguration. The summary had merged them into a single "timeout issue," and Claude was now answering from that merge instead of from the two distinct original reports. Marisol had to scroll back through her terminal history to find the original messages and re-paste both, because the session itself no longer had them in a form it could distinguish.
That's the actual cost: not that Claude Code becomes unusable, but that the person running triage becomes the fallback memory for their own tool, re-supplying details on demand that the session used to just have.
Where the native approach holds up, and where it stops
For a lot of Claude Code usage, none of this matters. Short sessions that stay under a session's practical working size never compact, and a session focused on one bug from report to fix rarely needs to recall a customer's exact wording from ninety turns back; the code itself is the memory.
It stops working specifically when a session does two things at once: it runs long enough to compact at least once, and it's tracking multiple distinct customer reports that need to stay distinguishable from each other. Triage queues are exactly that shape. A few mitigations help without solving the structural problem:
- Compact with instructions before it compacts on its own. Running
/compact Preserve every customer quote and account name verbatimat a natural break point gives you some control over what the summary keeps, instead of leaving it to Claude Code's default judgment. /clearbetween unrelated bugs. If a session is about to pivot from one customer's report to a different, unrelated one, clearing and starting fresh means there's no shared history to compact badly. The tradeoff is you lose continuity on anything that actually was related.- Keep a running triage doc outside the session. A Linear issue or a shared doc works; paste the original report text into it before Claude Code has a chance to summarize it away. This works, and it's also exactly the manual step that doesn't scale past a handful of bugs a day, because now a person has to notice, copy, and paste every report before the session gets long enough to compact.
That last point is the ceiling on the DIY approach. It depends on someone remembering to externalize the original text before compaction runs, every time, across every session, and that discipline erodes exactly when volume is high enough to need it most.
Past that point, the fix isn't better compaction settings inside the session. It's not keeping the original report inside the context window at all. Modem sits outside Claude Code and holds the durable record. It dedupes bug reports from Slack, support tools, and GitHub into topics, keeps the original customer quotes and account details attached to each one, and hands Claude Code a task built from that record when you route a topic to it through the Modem integration. The session Claude Code runs still compacts the way it always does, but it's re-fetching the original ask from the topic each time instead of relying on whatever survived the last summarization pass. That is our own product, so weigh this section as the vendor talking. It's also true that the manual habits above are enough on their own for triage sessions that stay short or stick to a single issue, and nothing here changes that.
For more on why per-session memory can't hold this on its own, see agent memory, explained. For the integration itself, the best tools to give Claude Code customer context compares this approach against the alternatives.
The tell that you've outgrown the manual fix
You don't need to guess in advance whether /compact instructions and a running triage doc are enough for your team. There's a concrete tell: the moment you catch yourself re-pasting a report or a customer quote into a session because Claude Code already lost it once. The first time that happens, it's a fluke, and the habits above will cover it. Once it's happening most days, the habits haven't failed. They've just hit the volume they were never built to handle, and that's the point where the record needs to live somewhere compaction can't touch it.
