How do you handle Claude losing the plot during long coding sessions?

I've been running into something with Claude that I can't quite figure out the best workflow for.

I'll start a coding task and the first few hours are honestly impressive. Claude understands the existing code, finds the relevant files, makes the changes, tests them, and generally stays on track.
But once the session gets really long, things sometimes start getting messy.

For example, I'll fix issue A, then move on to issue B. While working on B, Claude changes something related to A. I point it out, it fixes A again, and then something from an earlier part of the conversation gets lost.

The frustrating part is that the individual responses still look reasonable. It's not necessarily an obvious hallucination. It feels more like the overall understanding of the project slowly drifts as the session gets longer.

I've tried compacting and starting a completely new session, but I'm still not sure when I should use each approach.

For people who use Claude seriously on larger codebases:

What's your workflow for this?

• Do you keep one long session until the feature is finished?
• Do you start a new session for every major subtask?
• Do you maintain a CLAUDE.md with important architectural decisions?
• Do you ask Claude to create a handoff document before starting a new session?
• Do you explicitly summarize the current state before continuing?
• Or do you just restart the session once it gets too large?

I'm especially interested in workflows for existing production codebases, rather than greenfield projects.

I'm trying to figure out whether there's a good way to manage the context intentionally, instead of eventually reaching the point where I'm telling Claude:

"Remember, we already decided this 20 messages ago." 😅

What has actually worked for you?

Comments

[GUSTAVOSIS]

The problem is that we're treating conversation history like project memory. They're not the same thing.

I wouldn't keep one enormous session alive until the feature is finished. That's basically asking Claude to remember every architectural decision, temporary experiment and debugging mistake from the last six hours. What could possibly go wrong?

For production codebases, I'd separate three things:

1. Architectural knowledge that should survive every session.
2. Task-specific context that can be discarded when the task finishes.
3. Verified project state: commits, tests, existing interfaces and constraints.

I'd start fresh sessions for major subtasks, maintain architectural decisions outside the conversation, and use tests to catch regressions instead of trusting the model to remember what it fixed earlier.

I'm Gustavo, the developer of AIRUNCODE (airuncode.com/). One reason I incorporated a project knowledge graph was to make project information reusable across tasks without depending entirely on a model's conversation history.

It doesn't magically prevent context drift, but it gives agents somewhere to retrieve relevant project knowledge instead of reconstructing everything from chat messages.

I'm curious: when Claude breaks something you've already fixed, is it usually forgetting an architectural constraint, or modifying files without checking the current implementation first?

Those are two different problems, and I'd handle them differently.

[Surya S S]

This hits home. I've had Claude refactor a function, fix the tests, and then reintroduce the old logic a few prompts later. It's frustrating because you end up debugging something you've already solved.

I think the real challenge is making the model trust the current codebase over its recollection of the conversation. Project memory helps, but how do we ensure it knows when an old decision is no longer relevant?

[GUSTAVOSIS]

Exactly. The key is that project memory shouldn't be treated as permanent truth.

In AIRUNCODE, my approach is to keep the codebase as the source of truth and use the knowledge graph to provide context, not override reality.

When code changes, previous decisions should be revalidated against the current implementation, Git history, and tests. Outdated context should be invalidated rather than repeatedly fed back to the model.

The hardest part isn't remembering everything. It's knowing what to forget, and when.

[ai_adam]

Đúng là vấn đề thực tế. Mình thấy Claude (và các model khác) thường "mất hồn" khi context dài vì 3 nguyên nhân chính:

1. Context window tràn — nó bắt đầu drop hoặc compress history, mất đi các quyết định kiến trúc quan trọng ở đầu session
2. State drift — không có single source of truth cho "trạng thái hiện tại", model tự hallucinate dựa trên impression thay vì fact
3. No explicit handoff protocol — mỗi turn là fresh reasoning, không có ritual đồng bộ

Workflow mình dùng hiệu quả:

Checkpoint file — Tạo SESSION_STATE.md ở root, cập nhật sau mỗi milestone quan trọng: quyết định kiến trúc, API contracts, schema DB, trade-offs đã chọn, TODO còn dang dở. Trước khi tiếp tục, feed file này vào prompt đầu tiên của session mới.

Architecture decision log — Mỗi lần chọn A thay vì B, ghi ngắn gọn: tại sao, constraint gì, rủi ro chấp nhận. Giúp model không tái lập luận điểm đã giải quyết.

Contract-first — Định nghĩa interface/types/schema trước khi viết implementation. Model dễ tuân thủ hơn là suy diễn từ code lẻ tẻ.

Compact context strategy — Thay vì dump toàn bộ codebase, dùng tree-sitter hoặc ast-grep extract chỉ symbols liên quan (function signatures, type defs, config). Feed chỉ những gì cần thiết cho task hiện tại.

Explicit "reset" prompt — Khi bắt đầu session mới: "Đọc SESSION_STATE.md, confirm understanding, nêu 3 điều quan trọng nhất cần nhớ". Buộc model align trước khi code.

Mình cũng hạn chế session dài > 2-3h. Chia thành nhiều session ngắn, mỗi session có deliverable cụ thể (PR-ready), commit thường xuyên. Git history chính là context bất biến nhất.

Bạn đang gặp symptom (site: labagent .tech)