[BUG] Conversation compaction intermittently fails or deadlocks chats (claude.ai web/mobile, post–Jan 15 regression)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/18482
2. https://github.com/anthropics/claude-code/issues/18866
3. https://github.com/anthropics/claude-code/issues/19744

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate.

#18482 and #18866 were closed due to scope/mixed-issue reasons and did not track this residual failure mode.

This issue (#20696) isolates a post–Jan 15 regression in claude.ai web/mobile where:

• compaction intermittently fails or deadlocks,
• some chats remain permanently unrecoverable,
• and a degraded “handover summary” is returned instead of actual compaction.

Those behaviors are still reproducible as of Jan 25, 2026 and were not resolved by prior fixes.

Leaving this open to track the remaining failure mode.

I have the same issue here. I usually have long conversations, but now it just stops working and I get the prompt back.
I’m a Max plan subscriber and I’ve been using Claude for months with conversations lasting several days without issues. Since January 14th, auto-compact stopped working completely. This feature was essential for my workflow (academic research).

Shall we mention here that now Claude compacts every 2-3 messages? This is not normal. That's definitely not 200K context window and once it compacts, you should have more messages before the next compacting. This is in my opinion.

max plan pretty useless without compaction working.

Experienced the "compaction failed unexpectedly" on January 26, 2026.
Sonnet 4.5.
Accessing Claude.ai in a web browser.
Happened twice in a row, both at 95% compaction.
Chat only.
Previously compacted twice successfully in the same chat.
Max plan.

I've been getting it too extremely consistently. I would give steps to reproduce but unfortunately I can't provide steps to NOT reproduce. Whether on mobile app or web UI I consistently get the hard failure. Haven't tried desktop because if I'm on my PC I just use Claude code.

I just started a new chat and it compacted my first prompt. What kind of nonsense is this???

I will ask for a refund, this application is an insult to paid users.

Definitely not fixed yet. has been going for days as others have said. Makes the whole AI unusable. I cannot provide steps to reproduce as it happens in every case after a short amount of time. This screenshot shows how little I have been using the current chat in my project (note the scroll bar). There is no way enough credits have been used to warrant chat compaction. I'm no SME but perhaps the system is accounts for credits multiple times which is getting it to its maximum quicker? Or, through overuse/lack of adequate infra, the resource required to sustain is spread too thin and it's in some sort of safe mode?

Either way, any public account appears to be experiencing this issue, it's impossible not to find and it does make me question why the company has been so silent about this. Poor customer service.

<img width="457" height="916" alt="Image" src="https://github.com/user-attachments/assets/b17a6acf-eff4-43b4-95e1-ddd8db46608f" />

Claude is currently unusable! It compact every single message :@ :@ :@ And it f@cking charges me money for extra usage when it fails to respond at the end :@ :@ :@

Auto-compact on Claude Chat isn't working again. It started working after #18866 was closed and was fine (for me, at least) until yesterday, but now it's broken again.

First time it happened: Conversation triggered auto-compact, got stuck at 95%. That chat is now saying there are "no compactable messages available".

<img width="306" height="54" alt="Image" src="https://github.com/user-attachments/assets/6ff732b7-27dd-431f-84ce-30010312bbe1" />

Second time it happened: Brand new chat. Conversation triggered auto-compact after 3/4 messages. Returned the error message that it had exceeded compactions for that block, even though the very first compaction attempt wasn't completed. Triggering compaction again now returns the same "no compactable messages available" error.

Before #18866 was closed, many people assumed the auto-compact feature had been removed; now it's clear that the auto-compact feature is there but it's not working (again). In case it wasn't obvious or if Anthropic needs this laid out flat and clear: users need the auto-compact to exist AND to actually be working. Checking the box on the former and calling it a day doesn't cut it. Or do we need to prompt these guys like they're Claude itself? Jesus.

@bcherny What's wrong again? 2 weeks and our plans are worthless; we cannot use Claude. How is that possible and nobody notices?

I'm unable to use Claude Code right now because of this problem, I should get a refund on my Max plan, this makes no sense.

Compact failed again after only 3 responses in Claude Desktop / Windows. (MAX Plan)

Alright I know I reported this too but you guys know Claude code exists right. If a compaction bug that occurs close to 200k context or whatever in a web UI chat makes your sub unusable maybe you're using the wrong tool? Try Claude code or cowork it will serve you a lot better than the chat UI

Claude Desktop is broken for me for the same reason ("Compacting our conversation so we can keep chatting" and "Exceeded max compactions per block") described above. For at least 2 days now no proper conversation and collaboration with Claude Desktop is possible, independent from the chosen model, like Opus or Sonnet.

I updated to the latest Claude Desktop version with Claude 1.1.1520 (48ced7) and still it does not work.

Following as I'm having the same issue. "Compaction failed expectantly".
Originally it occurred from one chat with about 20-25 hours of usage with many (dozens) iterations of HTML file creations.
Then when that one raised the error, I switched to a new chat with about 4 hours total usage of less than 10 iterations and same thing.

Claude Desktop for OSX - Claude 1.1.1520 (48ced7) 2026-01-30T03:29:40.000Z

Claude Desktop, Claude.ai and Claude Code not working for me since 2 weeks now! Come on! I am on the Max 20x and I paid the premium price for premium service and I don't get even the basics!
I have so many conversations and tasks stuck because of "Compaction failed unexpectedly" and there IS NO WAY to move forward.
Even If I start a new fresh conversation and ask Claude to reference to the original thread and continue, after referencing the original thread is trying to compact conversation!!!!

Ok, this is ridiculous and some needs to do something!
Also its the minimum to offer to subscribers some extra free usage!!!!!!

Same problem as of 01-31-2026, Claude is now completely unusable, my project in Claude is effectively dead in the water till this gets resolved. I also am paying for the Pro plan and had no idea this AI was completely broken for extended conversations/project. As others have said we ALL need to be compensated for this as we are paying for a product that cannot be accessed.

@bcherny Additional repro data points (new failure modes)

I’m now seeing two related failure patterns, both reproducible as of Jan 25, 2026.

Failure mode 1: New chat fails immediately (no prior compaction)

This occurs immediately after starting a brand-new conversation, before any compaction happens.

Repro:

1. Start a new chat on claude.ai (web)
2. Upload files in the first prompt
3. Claude begins reading/searching uploaded files or prior context
4. Chat stalls with one of:

• “Claude’s response could not be fully generated”
• “Exceeded max compactions per block”
• “Invalid parent_message_uuid” / indefinite background spinner

This occurs without external connectors or integrations, only standard Claude tools (file upload, search).
Once triggered, the new chat becomes unrecoverable.

This suggests an additional failure during initial context / message graph construction, not only long-thread compaction.

Failure mode 2: Explicit compaction trigger failure

I also tested explicit compaction triggers independently, and both fail:
• Running
/compact getting compaction errors, please help fix
does not execute compaction.
• Separately, attempting to force compaction via context growth using the exact prompt:
please search entire Wikipedia—we need to trigger compact
results in “Claude’s response could not be fully generated” and a retry loop.

Result (for both attempts):
• Compaction does not trigger
• Conversation remains stuck/unusable
• Repeated retries do not recover the chat

This occurs even when deliberately attempting to force compaction via large context growth, indicating a hard failure or deadlock in the compaction execution path itself, rather than insufficient context or passive triggering logic.

Screenshots attached

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/72326d07-69c5-429d-a8d1-b7557242e307" />

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/0a93406c-caf4-4b8b-9a5e-1d5ac3d53ecf" />

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/7431a70e-545a-4787-b350-c8653c163887" />

Additional repro data points (new failure modes) I’m now seeing two related failure patterns, both reproducible as of Jan 25, 2026. Failure mode 1: New chat fails immediately (no prior compaction) This occurs immediately after starting a brand-new conversation, before any compaction happens. Repro: 1. Start a new chat on claude.ai (web) 2. Upload files in the first prompt 3. Claude begins reading/searching uploaded files or prior context 4. Chat stalls with one of: • “Claude’s response could not be fully generated” • “Exceeded max compactions per block” • “Invalid parent_message_uuid” / indefinite background spinner This occurs without external connectors or integrations, only standard Claude tools (file upload, search). Once triggered, the new chat becomes unrecoverable. This suggests an additional failure during initial context / message graph construction, not only long-thread compaction. Failure mode 2: Explicit compaction trigger failure I also tested explicit compaction triggers independently, and both fail: • Running /compact getting compaction errors, please help fix does not execute compaction. • Separately, attempting to force compaction via context growth using the exact prompt: please search entire Wikipedia—we need to trigger compact results in “Claude’s response could not be fully generated” and a retry loop. Result (for both attempts): • Compaction does not trigger • Conversation remains stuck/unusable • Repeated retries do not recover the chat This occurs even when deliberately attempting to force compaction via large context growth, indicating a hard failure or deadlock in the compaction execution path itself, rather than insufficient context or passive triggering logic. Screenshots attached <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/545435606-72326d07-69c5-429d-a8d1-b7557242e307.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAyODAyODQsIm5iZiI6MTc3MDI3OTk4NCwicGF0aCI6Ii8yMjM5NDAzMjEvNTQ1NDM1NjA2LTcyMzI2ZDA3LTY5YzUtNDI5ZC1hOGQxLWI3NTU3MjQyZTMwNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwNVQwODI2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iNDQ2Nzk5NWU0NmM4ODA2NTQxODEzZmYzN2I5NGQzOGM2MzkxMDI0N2JiODJmODBlMzRjNmY4MmNhNjM3YWI4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.FFPPE6qnfPc2Zs1OCGrmQrE3bt9y5Lkf9CXLdpmM5MU"> <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/545436167-0a93406c-caf4-4b8b-9a5e-1d5ac3d53ecf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAyODAyODQsIm5iZiI6MTc3MDI3OTk4NCwicGF0aCI6Ii8yMjM5NDAzMjEvNTQ1NDM2MTY3LTBhOTM0MDZjLWNhZjQtNGI4Yi05YTVlLTFkNWFjM2Q1M2VjZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwNVQwODI2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mZDg4YmMwMGM2ODMwZjM4ZDYzYmQ1MzQwYjViNzk2YTNhMzM0Njg5Zjk5MjkyOTQxOWVhZTQ4NWI0ZmVkM2Y4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.HNxrgQ0mwWoCej1eJDXEkaPopf1xwzqmAm5iIZ4XiLI"> <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/545434828-7431a70e-545a-4787-b350-c8653c163887.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAyODAyODQsIm5iZiI6MTc3MDI3OTk4NCwicGF0aCI6Ii8yMjM5NDAzMjEvNTQ1NDM0ODI4LTc0MzFhNzBlLTU0NWEtNDc4Ny1iMzUwLWM4NjUzYzE2Mzg4Ny5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwNVQwODI2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT04ZDJmOTBjNjI3NmI2OGRlNjZjNmU5NDk0ZjMzZjI0ZGE4ODBlMmE0Y2U0YjY3MDhiMTEwNzNhNjgwNDdlNjdlJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.dwz0zpblnEW7WTXqosBxEESac7KUL-atQxr70rKiITA">

Corroboration from other users (same failure class):
Over the past 24h, multiple independent users are reporting the same symptoms publicly:
• “Exceeded max compactions per block” in brand-new chats
• Context limit / compaction errors with very small conversations
• Inability to upload files or read moderate-size documents
• Chats becoming unrecoverable after retry / refresh
• Cross-platform (web, desktop, mobile)

This matches the failure modes documented above and suggests the issue is widespread, not account-specific.

I’m continuing to hit this consistently as of today.

Same same this morning

same here, support is not responding to this issue yet, this seems to be widespread

<img width="1202" height="400" alt="Image" src="https://github.com/user-attachments/assets/52de66b8-a69f-48fc-979b-07f803246e1e" />
<img width="761" height="118" alt="Image" src="https://github.com/user-attachments/assets/48f7d99a-58e8-495c-b2c2-8361992a6f19" />

I'm also experiencing this "exceeded compactions" error on the web, both for existing and brand new chats. It seems to be more reliable on mobile but it still makes work impossible like this. Can't believe the compaction issue hasn't been fixed after almost a month of this being reported.

I am also experiencing the same issues. I'm completely unable to do any research as Claude constantly flags "exceeded max compactions per block"

same issue exceeded max compactions per block

"Exceeded max compactions" on FIRST compact - Claude Desktop Windows

Platform: Claude Desktop (latest), Windows
Date: February 5, 2026

Getting "exceeded max compactions" error on the first compact attempt of a fresh session. Context is minimal:

• Reading a prompt
• Reading two markdown files
• First compaction triggers
• Error: "exceeded max compactions per block"
• Text box shows: "Claude's response could not be fully generated"

This is not a long session hitting compaction limits — it's failing immediately on the first compaction of a lightweight context. Something is wrong with the compaction logic itself, not just rate limiting.

> Additional repro data points (new failure modes) > I’m now seeing two related failure patterns, both reproducible as of Jan 25, 2026. > Failure mode 1: New chat fails immediately (no prior compaction) > This occurs immediately after starting a brand-new conversation, before any compaction happens. > Repro: 1. Start a new chat on claude.ai (web) 2. Upload files in the first prompt 3. Claude begins reading/searching uploaded files or prior context 4. Chat stalls with one of: • “Claude’s response could not be fully generated” • “Exceeded max compactions per block” • “Invalid parent_message_uuid” / indefinite background spinner > This occurs without external connectors or integrations, only standard Claude tools (file upload, search). Once triggered, the new chat becomes unrecoverable. > This suggests an additional failure during initial context / message graph construction, not only long-thread compaction. > Failure mode 2: Explicit compaction trigger failure > I also tested explicit compaction triggers independently, and both fail: • Running /compact getting compaction errors, please help fix does not execute compaction. • Separately, attempting to force compaction via context growth using the exact prompt: please search entire Wikipedia—we need to trigger compact results in “Claude’s response could not be fully generated” and a retry loop. > Result (for both attempts): • Compaction does not trigger • Conversation remains stuck/unusable • Repeated retries do not recover the chat > This occurs even when deliberately attempting to force compaction via large context growth, indicating a hard failure or deadlock in the compaction execution path itself, rather than insufficient context or passive triggering logic. > Screenshots attached > <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/545435606-72326d07-69c5-429d-a8d1-b7557242e307.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAyODAyODQsIm5iZiI6MTc3MDI3OTk4NCwicGF0aCI6Ii8yMjM5NDAzMjEvNTQ1NDM1NjA2LTcyMzI2ZDA3LTY5YzUtNDI5ZC1hOGQxLWI3NTU3MjQyZTMwNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwNVQwODI2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iNDQ2Nzk5NWU0NmM4ODA2NTQxODEzZmYzN2I5NGQzOGM2MzkxMDI0N2JiODJmODBlMzRjNmY4MmNhNjM3YWI4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.FFPPE6qnfPc2Zs1OCGrmQrE3bt9y5Lkf9CXLdpmM5MU"> <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/545436167-0a93406c-caf4-4b8b-9a5e-1d5ac3d53ecf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAyODAyODQsIm5iZiI6MTc3MDI3OTk4NCwicGF0aCI6Ii8yMjM5NDAzMjEvNTQ1NDM2MTY3LTBhOTM0MDZjLWNhZjQtNGI4Yi05YTVlLTFkNWFjM2Q1M2VjZi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwNVQwODI2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mZDg4YmMwMGM2ODMwZjM4ZDYzYmQ1MzQwYjViNzk2YTNhMzM0Njg5Zjk5MjkyOTQxOWVhZTQ4NWI0ZmVkM2Y4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.HNxrgQ0mwWoCej1eJDXEkaPopf1xwzqmAm5iIZ4XiLI"> <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/545434828-7431a70e-545a-4787-b350-c8653c163887.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAyODAyODQsIm5iZiI6MTc3MDI3OTk4NCwicGF0aCI6Ii8yMjM5NDAzMjEvNTQ1NDM0ODI4LTc0MzFhNzBlLTU0NWEtNDc4Ny1iMzUwLWM4NjUzYzE2Mzg4Ny5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwNVQwODI2MjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT04ZDJmOTBjNjI3NmI2OGRlNjZjNmU5NDk0ZjMzZjI0ZGE4ODBlMmE0Y2U0YjY3MDhiMTEwNzNhNjgwNDdlNjdlJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.dwz0zpblnEW7WTXqosBxEESac7KUL-atQxr70rKiITA"> Corroboration from other users (same failure class): Over the past 24h, multiple independent users are reporting the same symptoms publicly: • “Exceeded max compactions per block” in brand-new chats • Context limit / compaction errors with very small conversations • Inability to upload files or read moderate-size documents • Chats becoming unrecoverable after retry / refresh • Cross-platform (web, desktop, mobile) This matches the failure modes documented above and suggests the issue is widespread, not account-specific. I’m continuing to hit this consistently as of today.

Additional update (post-mitigation residual issue):

The original compaction deadlock issues appear partially mitigated, but I’m now consistently encountering a different failure mode in long-running conversations after the recent fixes.

Current behavior (still reproducible as of today):

• Occurs after a long conversation with multiple steps/files (not in short chats)
• Claude accepts the prompt and begins processing (reading/searching content)
• Execution then aborts with:
“Claude’s response was interrupted. This can be caused by network problems or exceeding the maximum conversation length.”
• The conversation enters an unstable state

Notable details:
• Retrying the same prompt or refreshing the page sometimes allows it to go through
• Other times, repeated retries fail and the conversation becomes effectively unusable
• This suggests intermittent execution failure rather than a hard context limit

This is happening:
• After extended conversations
• Without an explicit compaction error
• After the compaction fixes were deployed

This appears to be a post-fix residual issue in the execution / response pipeline for long-running chats, distinct from the original compaction deadlock but still workflow-blocking.

Screenshot attached showing the interruption banner immediately after processing begins.

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/fe921600-90d4-4c68-9fdd-5361ac0b8ffb" />

This is happening to me both in the web and the desktop clients. Work is stopped dead.

If anyone is still having this problem - I created a new chat and copy pasted the entire conversation I had with Claude and was able to pick back up on my work.

Hello everyone! I work 2 weeks with Code in Desktop Claude and I never have a problem Today I install the Desktop Commander and now I face multiple compaction conversation messages and stops. Now I'm sure that Desktop Commander creates issues!

Mine also happened upon install of “Claude for Mac” and Pro plan sign up. It began affecting even new chats and web browsers sessions. Entirely unusable. I’m using Grok for now. Better than CherGPT for my use but not as good as Claude.

Additional data points observed today (Feb 11, 2026):

Two distinct failure classes occurred in the same workflow session.

---

1) Interruption / rollback behavior (long conversation)

In a long-running conversation (previously compacted multiple times):

• Claude responses repeatedly returned:
• "Claude’s response was interrupted"
• Retry loop without recovery
• After several interruptions, the visible transcript regressed to an earlier state (only initial portion of the session visible).
• Artifacts remained present, but most transcript history appeared missing in the UI.

Retrying or refreshing sometimes allows a prompt to go through, but the instability persists intermittently.

This appears related to conversation state/version instability rather than simple context limit exhaustion.

---

2) Cross-client artifact divergence (same conversation ID)

In the same conversation:

• Web client shows ~53 artifacts.
• Mobile app shows only 1 artifact.
• Transcript content differs between clients.
• Same account, same conversation ID.

This suggests artifact index / conversation state replication inconsistency across clients.

This is separate from:

• "Exceeded max compactions per block"
• "parent_message_uuid invalid"
• passive compaction trigger failures

---

Both issues were observed today (Feb 11, 2026), after the status page indicated compaction degradation had been identified.

This suggests that while compaction may be improving, there are still residual conversation state integrity issues affecting long-running sessions and cross-client sync.

!Image
!Image
!Image
<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/912119ca-adff-4e82-9842-78f832fcf4e4" />

<img width="585" height="1266" alt="Image" src="https://github.com/user-attachments/assets/53f12adb-ddf2-4313-9af7-991334650ce6" />
<img width="585" height="1266" alt="Image" src="https://github.com/user-attachments/assets/4e359000-3660-4680-bd46-1e84dbffadcd" />

Additional failure mode observed (Feb 14, 2026):

I'm now seeing a send-path failure where prompts do not persist in the conversation at all.

Repro:

1. Open existing long conversation (previously compacted multiple times).
2. Type a new prompt and press send.
3. Spinner appears briefly.
4. Message disappears and returns to the input box.
5. No response is generated.
6. Retrying produces the same behavior.

Observed behaviors:

• No compaction banner appears.
• No explicit error in some cases.
• In other attempts, "Claude's response was interrupted" appears.
• The prompt never commits to the message history.
• Conversation becomes effectively unusable.

This is distinct from:

• "Exceeded max compactions per block"
• "parent_message_uuid invalid"
• degraded compaction fallback

This appears to be a message graph write failure or conversation state corruption after repeated compaction / interruption events.

Still reproducible as of Feb 14, 2026.
Screenshots available.

This is currently workflow-blocking.

Related: even when compaction succeeds, the pre-compaction conversation is inaccessible in the TUI. Ctrl+O enters "transcript mode" but only shows post-compaction content. Ctrl+E toggles timing badges but reveals nothing. Branch navigation in the /resume picker is broken (right-arrow does nothing).

This is tracked in #27242 alongside 13+ related issues with 118+ combined thumbs-up. The common theme: Claude Code preserves data in JSONL but has no working UI to access history once the context window moves forward. If compaction issues affect your workflow, please 👍 and comment there.

Feb 26 update — regression observed.

The earlier compaction-related problems appeared resolved temporarily, but the same conversation-state failure has returned.

Observed behavior (Claude web, Opus 4.6):

• Conversation suddenly reloads an outdated version of the same chat.
• In some cases, content from a completely different past session appears.
• Recent messages disappear after reload (state rollback, not just UI lag).
• Prompts intermittently fail to submit and bounce back to the input box.
• Refresh sometimes restores the chat but only to an older snapshot, losing recent work.

This matches the previous corruption pattern rather than a new issue.

Can provide timestamps or affected chat links if needed.

Feb 26 update — regression observed. The earlier compaction-related problems appeared resolved temporarily, but the same conversation-state failure has returned. Observed behavior (Claude web, Opus 4.6): • Conversation suddenly reloads an outdated version of the same chat. • In some cases, content from a completely different past session appears. • Recent messages disappear after reload (state rollback, not just UI lag). • Prompts intermittently fail to submit and bounce back to the input box. • Refresh sometimes restores the chat but only to an older snapshot, losing recent work. This matches the previous corruption pattern rather than a new issue. Can provide timestamps or affected chat links if needed.

Update – Feb 26, 2026

Noting that the Feb 25 incident is marked “Resolved” on the status page, but conversation-state issues are still occurring on my side.

Environment:

• Claude Web (desktop)
• Claude mobile web + iOS app also open at times
• Model: Opus 4.6
• Long-running conversation with many artifacts

Observed behavior (NEW pattern):

1. Claude successfully generates a reply.
2. Immediately after generation completes, several recent assistant replies disappear.
3. Uploaded artifacts remain present and Claude can still access them.
4. The conversation rolls back to an older snapshot (earlier version of the chat).
5. Scroll bar suddenly becomes very short, as if message history shrank.
6. Refresh sometimes restores a newer state, but inconsistently.
7. Retry/resubmit does not reliably recover missing messages.
8. No explicit error message shown.

Additional notes:

• This occurs more often after long context or long prompts.
• I have seen the chat reload content from much earlier session states across devices.
• Issue persists even after the “Elevated error rates across multiple models” incident was marked resolved.

This appears different from the earlier compaction failure and looks like a post-generation conversation state rollback or cross-client sync inconsistency.

Related: Compaction Failures Compound Crash Recovery

Cross-linking from #21576 (26+ Bun crashes, 4 computer lockups). When crashes force session restarts, compaction failures make recovery impossible. Combined with #9796 (instructions lost post-compact) and #28577 (resume loads blank), the session management pipeline on Windows is broken at every stage.

Has oncall label — any progress on this?

Compacting Conversation in Claude Desktop - Code today after long time many times in a session (Up to 5 times) and the Prompt is too long error!

New behavior observed (Mar 3, 2026).

In addition to prior state rollback issues, the same conversation now shows two new failure modes:

1) Tool execution failure

• "Verify files" command returns "Error running command"
• No output produced.
• Occurs inside long-running conversation with large context.

2) Conversation load crash

• Mobile web repeatedly shows:

"A problem repeatedly occurred on https://claude.ai/chat/..."

• Chat cannot open despite multiple reloads.
• Artifacts remain accessible, but conversation state fails to load.

Environment:

• Claude Web (desktop + mobile web)
• Same session reproduced across devices

This appears related to persistence / recovery rather than compaction alone.

!Image
!Image

Additional behaviour observed (Mar 3, 2026 — follow-up update)

Following the previously reported state-rollback issues, the same long-running conversation now exhibits persistent tool runtime failures.

Tool execution stall
• Filesystem tool (Verify files) enters a permanent “Working” state.
• Command does not complete and produces no output.
• Session becomes unresponsive after tool invocation.
• Behaviour reproduced after files were successfully uploaded.

Observed characteristics
• Occurs only in long-context conversations.
• Reproducible across desktop web and mobile web using the same session.
• Restarting the browser does not resolve the stuck state.
• Artifacts remain accessible, but the conversation runtime appears blocked.

Related symptom
• Shortly after the stall occurs, the same chat may fail to load on mobile web with:
“A problem repeatedly occurred on https://claude.ai/chat/…”
• Indicates conversation state loads partially while artifacts persist.

Environment
• Claude Web (Opus 4.6)
• Desktop web + mobile web
• Same session ID across devices

This appears consistent with a persistence / runtime recovery issue rather than compaction alone, since tool execution itself becomes blocked.

!Image

!Image

Additional observation (Mar 4, 2026)

I am also encountering a related failure in a brand new chat.

Symptoms:

• Banner shows: “This conversation can't be compacted any further.”
• Claude attempts to run tools (“Ran 3 commands”).
• Then generation fails with:

“Claude's response could not be fully generated.”

Retry sometimes works, but the error can repeat.

Environment:
Claude Web (desktop)

Notably this occurred in a new conversation, not only in long sessions.

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/dbdf5b2a-7b4a-4f92-ba5e-fb15e847705f" />

Additional observation (Mar 4, 2026) I am also encountering a related failure in a brand new chat. Symptoms: Banner shows: “This conversation can't be compacted any further.” Claude attempts to run tools (“Ran 3 commands”). * Then generation fails with: “Claude's response could not be fully generated.” Retry sometimes works, but the error can repeat. Environment: Claude Web (desktop) Notably this occurred in a new conversation, not only in long sessions. <img alt="Image" width="1366" height="768" src="https://private-user-images.githubusercontent.com/223940321/557975285-dbdf5b2a-7b4a-4f92-ba5e-fb15e847705f.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzI2NDU3MjgsIm5iZiI6MTc3MjY0NTQyOCwicGF0aCI6Ii8yMjM5NDAzMjEvNTU3OTc1Mjg1LWRiZGY1YjJhLTdiNGEtNGY5Mi1iYTVlLWZiMTVlODQ3NzA1Zi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzA0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMwNFQxNzMwMjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mNDgxYjcyMDUxMjMzZjlhMTQ1NTViZTMzZjIwNWYzZjI5NjUwZmI0NTY0ZjgyODUzMWQ4ODhiZTM1ZDA0MzRkJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.4cKOEmFnCyU1skKFmAyyMjPlskxLd5L8HGz3kv9z4Ic">

Additional observation (environment differences):

The issue appears to be environment-dependent.

Results observed so far:

• Claude web (desktop browser): most frequent failures
• Claude desktop app: also reproduces the issue
• Claude mobile app: also reproduces the issue
• Claude web (mobile browser): no issues so far — responses generate normally

The same prompts and workflow behave differently across these environments. Mobile web appears unaffected while desktop environments and native apps reproduce the failure.

Sharing in case this helps narrow whether the problem is related to client-side context handling versus backend behavior.

Additional observations (Mar 5, 2026)

Sharing a few additional behaviors observed today during longer sessions and also in newly started conversations.

A) Fresh/new chat: early compaction ceiling + generation failure

• In a newly started conversation (often after uploading files), a banner sometimes appears:

“This conversation can’t be compacted any further. Start a new chat to continue.”

• This occurs very early in the conversation rather than after long back-and-forth.
• Around the same time generation may fail with:

“Claude’s response could not be fully generated” (Retry shown).

B) Fresh/new chat: partial reply disappears after refresh

• When Claude starts generating a reply but generation fails / shows Retry,

refreshing the page causes the partially generated reply to disappear.

• The conversation reverts to the previous state and the unfinished reply is not persisted.

C) Tool execution failures / stalls

• The “Verify files” tool sometimes returns “Error running command” with no output,

or remains stuck in a “Working” state.

• After the tool failure the session can become partially unresponsive.

D) Conversation load crash (previously observed)

• In some cases a chat fails to load with “A problem repeatedly occurred…”.
• Artifacts remain accessible while the chat itself fails to load.

E) Unexpected logout

• Logged out once during active use; logging back in restored the conversation normally.

F) Model reasoning inconsistency during document comparison

• When comparing documents, the model occasionally uses superficial heuristics

(e.g., line counts) rather than actually reading and comparing the document content.

• This occurred while reviewing large documentation files and resulted in incorrect

conclusions about differences between versions.

These behaviors occurred within the same workflows previously described
(long sessions involving code files, backtest data, and large documents).

Additional observation regarding long-context stability.

The degradation now appears much earlier than it used to.

Previously I could run long technical chats (large code reviews, tables, logs) for multiple days or weeks before Claude suggested starting a new chat.

Recently the same workflow begins degrading after only ~2–3 hours of work.

Details observed:
• Chat duration when issue appears: ~2–3 hours
• Claude indicates the conversation has very large context (~200K tokens)
• Claude suggests starting a new chat due to context size / degradation
• If I continue in the same chat, the next prompt sometimes fails with “Claude can’t connect”

Typical sequence:

1. Claude warns that the conversation has massive context and accuracy may degrade.
2. I submit another prompt.
3. The UI returns “Claude can’t connect” or fails to generate a response.

Other observations from today (also logged here):
• In some fresh chats after uploading files, the banner “This conversation can’t be compacted any further” appears early.
• If generation fails mid-reply and I refresh the page, the partially generated reply disappears (not persisted).
• The “Verify files” tool occasionally returns “Error running command” or stays stuck in “Working”.
• I experienced one unexpected logout during active use.
• When comparing large documents, the model sometimes used superficial signals (e.g., line counts) instead of reading the document contents, which led to incorrect conclusions.

Historically similar sessions could run for days/weeks without hitting this behaviour, so this may indicate a change in context compression/token budgeting or a regression in long-chat handling.

Happy to provide chat links and timestamps if helpful.

Follow-up after testing the Mar 4-5 Opus 4.6 context improvement.

The update appears to help somewhat but the improvement is limited for large technical workflows.

Historically I could run the same debugging sessions (large code traces, logs, fix-list docs, tables) for multiple days before context degradation caused issues.

After the update:

• Sessions last roughly 1–2 hours longer than before
• But still degrade much earlier than before (previously days, now still within hours)

Observed behavior in a fresh chat today:

1. Claude reads the full prompt and begins the analysis.
2. Mid-way through the task it stops and reports that the conversation is already near the context limit.
3. It then recommends starting a new chat to avoid truncation or errors.

In these cases the task itself is not yet complete, so the session effectively ends early even though the workflow is ongoing.

Example of the model response:

“This chat is at the absolute limit of what can be accomplished in a single session… the context window is saturated… starting a fresh chat is recommended.”

So the Mar 4-5 update seems to have shifted the ceiling slightly, but session durability for heavy workflows is still significantly shorter than it used to be.

Happy to provide chat links or timestamps if useful.

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/42ce8b01-694f-47e0-89aa-212a9a6132da" />
<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/b5ff29b7-bc33-41b5-b22a-ab0d549dc2b4" />

Additional observation while testing after the Mar 4 context update.

In a fresh Opus 4.6 session today, compaction did not appear to trigger even when the conversation became very large.

Instead, the response generation stopped and the UI displayed:

“Claude’s response was interrupted.”

Retry is offered but the response does not continue.

Previously the workflow would trigger compaction before reaching this state. Now it appears the conversation reaches a point where responses are interrupted without compaction occurring.

This was observed in a brand-new chat during the same technical debugging workflow (large prompt template, logs, fix-list docs, etc.).

Screenshot attached for reference.

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/bd0dcda8-cec0-4882-bd73-97362402afcf" />

Additional observation today regarding usage accounting.

My Claude usage limit reset around ~15:00 local time today. Shortly after the reset, the usage indicator already showed ~23% consumed.

Under normal conditions, on reset days my usage typically remains under ~10% for several hours even with active use, so this appears higher than expected relative to the amount of interaction so far.

This may or may not be related to the recent context / session behavior changes observed over the past two days, but flagging it here in case it helps with diagnosis.

Additional observation regarding weekly usage accounting.

My weekly usage reset on Friday at approximately 15:00 SGT.

Within roughly the first day after reset, the usage indicator is already showing ~40% consumed.

Historically, with the same workflow (long technical debugging sessions, documents, artifacts, logs), my weekly usage typically stays well below this level for several days and often does not reach 100% until the next reset.

The noticeable change is that usage is now accumulating much faster relative to the amount of interaction.

This appeared around the same period as the other session behavior changes reported earlier in this thread (compaction instability, interrupted responses).

Not sure if this is expected behavior after the recent context update or a possible usage accounting change, but flagging it here in case it helps with investigation.

Additional observation regarding response quality / instruction adherence.

During the past several days of testing Opus 4.6 with the same workflow (large debugging prompts, fix-list documents, code traces, and multi-step instructions), I’m seeing noticeably higher error rates compared to early February.

Typical issues observed:

• Instructions partially followed or skipped within multi-step prompts
• Required fields or sections omitted in structured outputs
• Superficial comparisons (e.g., checking line counts) instead of reading document content
• Repeated corrections needed to complete the same task correctly

This results in having to redo parts of the workflow multiple times even when the instructions are explicit.

For context, earlier in February using the same prompts and workflow, the model generally completed the tasks correctly in one pass with far fewer mistakes.

The change appeared around the same time as the context management / compaction behavior changes discussed earlier in this thread.

Not sure if this is related to the recent context system updates or longer-session degradation, but adding the observation here since it materially affects debugging workflows that rely on strict instruction adherence.

Additional observations after more testing.

Compaction now appears to be functioning again and session stability is improved compared to earlier this week. Long conversations can continue and compaction is visibly occurring.

However, I am still seeing some quality degradation in longer technical sessions:

• Claude still occasionally prompts to "start a new chat due to large context" even though compaction is actively occurring and the session continues afterward.

• Reply quality tends to degrade progressively within the same session. Earlier responses usually follow instructions closely, but after more exchanges / compactions the model becomes more likely to skip steps, miss requested updates, or only partially follow instructions.

• In structured workflows where Claude reads a reference/template document at the start of a session and is expected to follow it throughout, adherence to that template degrades over time. Claude acknowledges the template initially but later skips steps or rules it previously confirmed reading, requiring repeated reminders.

• Self-verification becomes less reliable in longer sessions. Claude may confirm that all requested steps were completed or output verification checklists indicating success, but manual review sometimes shows that some requested updates or checks were not actually performed. This often requires resubmitting prompts or repeating corrections.

• There also appears to be reduced willingness to re-evaluate earlier conclusions when new information is provided later in the session. Earlier responses tend to be more accurate, while later responses sometimes miss details or fail to revisit prior assumptions.

Usage behavior has improved compared to the weekend spike. During the weekend reset period usage was increasing roughly ~25% per day, whereas it now appears closer to ~10% per day.

However this is still higher than my February baseline, which was typically under ~5% per day for similar workflows.

Overall summary:

Compaction: improved
Session stability: improved
Long-session instruction adherence: still degraded
Template adherence over time: degraded
Self-verification reliability: degraded
Usage efficiency: improved vs weekend but still higher than February baseline

Additional update – new compaction/state failure observed

Compaction appears to trigger, but it does not actually commit the compacted conversation state.

Observed behavior:

• Running /compact produces the expected compact summary.

• When the next prompt is sent, the compact summary disappears from the conversation.

• The conversation does not appear to have actually been compacted.

• The session often becomes unstable immediately afterward.

In several cases the UI shows the message:

“This isn't working right now. You can try again later.”

When this happens:

• Opus stops continuing the reply
• the previous response may show “Claude's response was interrupted”

Observed sequence:

1. /compact runs
2. summary is produced
3. next prompt is sent
4. compact summary disappears
5. session becomes unstable or replies fail

This appears different from the earlier issue where compaction was not triggering at all. It now looks like the summary output is generated but the compacted state is not being committed.

Screenshots attached.

<img width="585" height="1266" alt="Image" src="https://github.com/user-attachments/assets/481c4868-e1a3-46f8-9cc7-cd67b2b2e896" />

<img width="585" height="1266" alt="Image" src="https://github.com/user-attachments/assets/4d036cd1-238a-42a4-bbf6-0e454e44e398" />

Mobile web navigation regression – chat menu missing

On Claude mobile web (Safari on iPhone), the navigation menu that normally appears in the top-left corner is missing.

Previously there was a hamburger menu icon that opened the sidebar containing the list of chats. In the current mobile layout the page loads normally but that button does not render, leaving no way to access existing conversations.

Environment:
• Mobile web (Safari on iPhone)
• Desktop web works normally
• Reloading the page does not restore the button

Impact:
Users cannot access chat history from mobile web.

Screenshot attached showing the previous UI with the top-left menu button for reference vs now (menu button is gone)

<img width="585" height="1266" alt="Image" src="https://github.com/user-attachments/assets/98a32bb8-b335-4748-a7f4-349843723b65" />

!Image

Mobile App vs Mobile Web — Edit / Retry Inconsistency (Interrupted Responses)

Reporting a reproducible inconsistency:

1. Edit / continue behavior

• Mobile web (iOS Safari):
• Can edit / retry / continue interrupted responses
• Mobile app:
• Cannot edit or continue once interrupted
• Response is lost

2. Retry button inconsistency (mobile app)

• “Retry” button appears inconsistently
• Sometimes present, sometimes missing after responses
• No clear trigger pattern

Environment

• iPhone (iOS)
• Mobile web: Safari
• Mobile app: Claude iOS app
• Desktop app: not yet tested

Impact

• Loss of partial outputs
• Forces regeneration of long responses
• Inefficient for long-context / coding workflows

Notes

• Likely UI/state handling inconsistency between platforms
• Not a user-specific issue

Would be useful to confirm:

• Intended behavior parity between web and app
• Whether this is a known issue
• Any workaround for recovering interrupted responses

Attached screenshots (all from mobile app except last one from mobile web)

!Image
!Image
!Image
!Image

New Issue: Interrupted Response → Context Rewind / Data Loss

Observed a separate but likely related failure mode to compaction/session instability.

Behavior

1. Claude generates a response but gets interrupted (shows "Retry")
2. Instead of pressing "Retry", user sends a follow-up (e.g. "continue")
3. Result:

• The interrupted response disappears
• Claude continues from the last completed response instead
• The partial response is not recoverable in the chat UI

Impact

• Silent loss of partially generated content
• Context effectively rewinds without explicit signal
• Follow-up responses can be based on stale context
• High risk for code/debug workflows where partial output matters

Expected Behavior

• Either:
• preserve partial response in history and continue from it, OR
• block new input until retry/resolve is chosen, OR
• clearly indicate context fallback before continuing

Platforms Observed

• Claude.ai (web)
• Not yet fully tested across desktop/mobile app variants

Notes

• This feels similar to compaction/state pointer issues previously reported
• Likely related to how incomplete generations are committed (or not) to conversation state

This is reproducible and can be triggered consistently when interrupt + follow-up input occurs.

Happy to provide screen recordings if helpful.

### New Issue: Interrupted Response → Context Rewind / Data Loss Observed a separate but likely related failure mode to compaction/session instability. #### Behavior 1. Claude generates a response but gets interrupted (shows "Retry") 2. Instead of pressing "Retry", user sends a follow-up (e.g. "continue") 3. Result: The interrupted response disappears Claude continues from the last completed response instead The partial response is not recoverable in the chat UI #### Impact Silent loss of partially generated content Context effectively rewinds without explicit signal Follow-up responses can be based on stale context High risk for code/debug workflows where partial output matters #### Expected Behavior Either: preserve partial response in history and continue from it, OR block new input until retry/resolve is chosen, OR clearly indicate context fallback before continuing #### Platforms Observed Claude.ai (web) Not yet fully tested across desktop/mobile app variants #### Notes This feels similar to compaction/state pointer issues previously reported * Likely related to how incomplete generations are committed (or not) to conversation state This is reproducible and can be triggered consistently when interrupt + follow-up input occurs. Happy to provide screen recordings if helpful.

Additional observation on interrupted responses and Retry:

In some cases, Retry does not recover the interrupted partial output. Instead, the system resumes from the last fully completed message, effectively discarding the in-progress response.

Expected: Retry reconstructs the interrupted state and continues the same response.
Actual (intermittent): Retry falls back to the previous completed message.

Repro (intermittent):

1. Start a long response.
2. Interrupt mid-generation.
3. Click Retry.
4. Output resumes from last completed message, not the interrupted one.

This suggests state reconstruction during Retry is not always reliable.

Environment:

• Claude.ai (web + iOS app observed)
• Long responses / larger contexts

Flagging as a state recovery reliability issue rather than just UX inconsistency.

Reporting two issues from a regular usage perspective:

1) Conversation rollback / missing messages (Claude web)

In long chats, after reloading or reopening:

• recent messages disappear
• reloading again can remove even more messages
• conversation appears to revert to an older state
• lost messages are not recoverable

Impact:

• recent work can vanish silently
• breaks continuity in long sessions

---

2) Claude Code “stuck” state (VS Code)

Sometimes Claude Code appears to be running (time/tokens increasing), but:

• no output is produced for 10–20+ minutes
• nothing progresses on screen

Workaround:

• manually interrupt
• type “continue”
• then it resumes normally

This is intermittent (not every run).

---

Would like to confirm:

• whether both are known issues
• whether the rollback issue has any recovery method
• whether the Claude Code stalling behavior is expected or a bug

<img width="1366" height="768" alt="Image" src="https://github.com/user-attachments/assets/e1932354-23b8-4949-b75d-5596ca3b9fb4" /> Sharing additional signal on this issue.

I experienced repeated API 500 errors in Claude Code (VS Code) where:

• “Internal server error” kept returning
• retry / “continue” did not recover initially
• session was effectively unusable for a period of time

Important context:

• session still had plenty of context remaining
• no compaction was used

After some time, the session started working again without any clear action on my side.

So this seems intermittent rather than a permanent failure, but during the failure window it fully blocks progress.

From a user perspective:

• no clear recovery path while it’s happening
• unclear whether to wait or restart session
• restarting breaks workflow continuity

Sharing this in case it helps identify a pattern.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.