Skip to content

[BUG] resume flag fails to maintain conversation context after hitting usage/context limits #3138

New issue
New issue
Open
Open
[BUG] resume flag fails to maintain conversation context after hitting usage/context limits#3138
Labels
area:corebugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:linuxIssue specifically occurs on Linux

Description

@jamiejsmith96
jamiejsmith96
opened on Jul 8, 2025

Bug Summary:
When a Claude Code session hits context/usage limits and ends with "Claude AI usage limit reached", the --resume
flag completely fails to restore any conversation context, resulting in total loss of session state.

Steps to Reproduce:

  1. Start a Claude Code session and work on a multi-step task
  2. Session hits context/usage limits and displays "Claude AI usage limit reached|[timestamp]"
  3. Restart Claude Code with --resume flag
  4. Previous conversation context is completely lost despite resume flag

Expected Behavior:
The --resume flag should restore conversation state even after hitting limits, allowing continuation of work with
maintained context.

Actual Behavior:

  • Complete loss of conversation history after hitting limits
  • --resume provides no recovery of previous session state
  • User must re-explain entire project context and tasks
  • System shows "Claude AI usage limit reached|1751911200" but no context restoration

Impact:

  • Makes long development sessions impossible to continue
  • Context limits become session-ending rather than manageable interruptions
  • Undermines the core value of persistent AI assistance for complex tasks
  • Forces users to restart complex workflows from scratch

Environment:

  • Platform: linux
  • OS: Linux 5.15.167.4-microsoft-standard-WSL2
  • Date: 2025-07-08

Additional Context:
This suggests the resume functionality doesn't properly handle context limit scenarios, making it ineffective
when most needed.

Activity

  1. jamiejsmith96
    added
    bugSomething isn't working
    on Jul 8, 2025
  2. github-actions
    added
    has reproHas detailed reproduction steps
    platform:linuxIssue specifically occurs on Linux
    area:core
    memory
    on Jul 8, 2025
  3. dicksontsai
    assigned
    ghost
    on Jul 8, 2025

  4. realSater commented on Sep 15, 2025

    @realSater
    realSater
    on Sep 15, 2025

    I’m aware that similar issues have been raised, but in addition to the point mentioned above, it's also important to note that when reusing subagents (i know subagents are stateless) with /resume inside claude cli, previous tasks or actions are lost if the conversation reaches usage limits - meaning there is no track or realtime update on the status of agents' progress.

  5. Lonli-Lokli commented on Nov 27, 2025

    @Lonli-Lokli
    Lonli-Lokli
    on Nov 27, 2025

    Does it happen with GitHub app as well?

  6. github-actions commented on Dec 28, 2025

    @github-actions
    github-actionsBot
    on Dec 28, 2025 – with GitHub Actions

    This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

  7. github-actions
    added
    autocloseIssue will be closed automatically
    and removed
    autocloseIssue will be closed automatically
    on Dec 28, 2025

  8. alessio-locatelli commented on Jan 18, 2026

    @alessio-locatelli
    alessio-locatelli
    on Jan 18, 2026

    Claude Code version 2.1.12 still fails to resume the conversation or continue work when the rate limit is hit while a sub‑agent is running. Users have to restart from scratch or manually prompt the agent to determine where it was interrupted. This should be treated as a high‑priority bug.

  9. NJManganelli commented on Feb 4, 2026

    @NJManganelli
    NJManganelli
    on Feb 4, 2026

    Considering the impact on one's paid-for limits, this is a pretty egregious bug to have. Even within an active session, initiating /resume after the limits reset just re-triggers the message that one has hit the limit, erroneously. Additionally, there seems to be discrepancies between the limit the session is measuring against and the usage from one's usage on the website (even after waiting hours for any trickle-in statistics to filter in), so that's yet another (related) bug.

  10. clutchwave commented on Feb 24, 2026

    @clutchwave
    clutchwave
    on Feb 24, 2026

    Just ran into this. Would be nice to have this handled with a clean 'pause' given the costs.

    In the meantime, Telling it continue got it going again, but it seemed to have lost where it was and had to start over, killing a few extra tokens.

  11. frankschlegel commented on Feb 25, 2026

    @frankschlegel
    frankschlegel
    on Feb 25, 2026

    I found that "continue where you left off" works pretty well.

  12. marksirota commented on Mar 21, 2026

    @marksirota
    marksirota
    on Mar 21, 2026

    This bug is still extant, or at least a very similar one. Claude Code 2.1.70.

    After compacting, Claude Code reported "You've hit your limit · resets 4am (America/New_York)" after cooking for 10:44. I waited the several minutes until 4am and found it had no knowledge of the session, going back to 03:09 based on timestamps on files we were working on.

    Because it clears the terminal scroll back buffer when it compacts, I couldn't even scroll back to get it. So I lost an hour of work, an hour of sleep, and an hour of credits to this bug.

  13. sannidhyaroy commented on Mar 22, 2026

    @sannidhyaroy
    sannidhyaroy
    on Mar 22, 2026

    The bug is still relevant. This should've been treated with high-priority, yet here we're still losing all conversational context in a deep session and no way to redeem it. Auto-compaction is dangerous and I learnt it the hard way, I'll just turn off because this issue doesn't look like will be addressed soon anyway.

  14. Gerardopaper commented on Mar 31, 2026

    @Gerardopaper
    Gerardopaper
    on Mar 31, 2026

    Still having this bug, I think Anthropic wants me to pay for additional use and that's why still not solved

  15. edward-b-1 commented on Mar 31, 2026

    @edward-b-1
    edward-b-1
    on Mar 31, 2026

    I have also noticed this bug. There should probably be some kind of UI element added to the various interfaces to Claude to "Try resume" after the notification about the limit being hit has been displayed

  16. ggsklias commented on Apr 8, 2026

    @ggsklias
    ggsklias
    on Apr 8, 2026

    Still having this bug today on MacOS. When will this be planned? All my conversations cannot be resumed anymore which creates an incredibly frustrating/unusable situation.

  17. erikd commented on Apr 11, 2026

    @erikd
    erikd
    on Apr 11, 2026

    I ran into this issue and was repeatedly issuing a "continue" command needlessly burning tokens for zero results.

    At the VERY least, when Claude halts because it runs out of tokens, a warning should be issued that Claude may loose context,

  18. clutchwave commented on Apr 17, 2026

    @clutchwave
    clutchwave
    on Apr 17, 2026

    Just had this happen again:

      ⎿  You've hit your limit · resets 10am (America/Chicago)
                                                            
✻ Churned for 7m 50s                         
                                                              
❯ /rate-limit-options                                                                
                                                   
─────────────────────────────────────────────────────────────────────────────────────
  What do you want to do?              
                                                                                     
    1. Stop and wait for limit to reset
  ❯ 2. Request more

    By the time I got back to the console, it was already past 10am though.

    The obvious default would be to have it wait and automatically resume once the limit has reset, maybe even give it a few random minutes so the compute doesn't get slammed at the top of every hour.

    There's got to be better ways of handling this

  19. ChadS24 commented on May 5, 2026

    @ChadS24
    ChadS24
    on May 5, 2026

    Have had this exact issue happen to me multiple times and it is becoming a deal breaker. I've had it stop when it was right in the middle of writing code leaving me with broken code that needs to be rolled back to the previous commit. And just like everyone else has mentioned I then have to burn through more tokens either redoing the work that was partially completed or trying to salvage the partially completed work. Either credit us back for the wasted tokens, keep the context so that we are able to pick back up or do like Codex does and at least finish out the current task!

  20. alopez3006 commented on Jun 26, 2026

    @alopez3006
    alopez3006
    on Jun 26, 2026

    try this repo : https://github.com/Snipara/snipara-companion it does exactly that... resume the work so Claude can continue the job using the hooks...

  21. drkh-n commented on Jul 16, 2026

    @drkh-n
    drkh-n
    on Jul 16, 2026

    Hey, I solved the problem the way it cost 0 tokens. No need to write into memory or save what Claude was doing. No need for Claude to re-read. No need to run prompt again manually. Check out this project I'm working on: https://github.com/drkh-n/claude-hibernate
    You can see the demo how it works.

  22. FDBnet commented on Aug 17, 2026

    @FDBnet
    FDBnet
    on Aug 17, 2026

    This happened to me. It’s really annoying. Dear Anthropic devs, how about fixing this by taking a "snapshot" or simply saving a "checkpoint" when 95% of the limit is reached?

  23. hjk-sys commented on Oct 28, 2026

    @hjk-sys
    hjk-sys
    on Oct 28, 2026

    In case it helps anyone here while waiting: npx decompact reads the local session logs and shows everything, including messages hidden by compaction and branches you rewound away, with search across all sessions. I wrote it, source: https://github.com/hjk-sys/agentlog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:corebugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:linuxIssue specifically occurs on Linux

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions