[BUG] Compaction seems to be destructive to summarized context, leading to incorrect next actions taken by "lost and confused" model

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?

Whenever compaction occurs in Claude Code, either automatically or by command, this seems to result in destructive consequences to the remaining context. I have noted that with a majority of compactions, the next actions the agent takes afterwards (in the case of automatic) are usually incorrect, and often based on earlier work that was being done well before compaction occurred.

The agent will state that "based on the summary" it was continuing "X", so it seems that the summarization process is not necessarily....prioritizing the preservation of recent-work details, or necessarily the timeline of operations and work performed. The recent case that lead to me posting this bug report, I was working on testing, evaluation and refinement of the most recent code implemented (which was driven by detailed plans.) This process was driven by simple progressive prompting, running tests against a RESTful API server and local DB, evaluating results, and refining/debugging the implementation. Periodically I would instruct the Claude Code to commit. I committed relatively early after the previous compaction, then was performing ongoing httpie testing and fixing a notable bug that had been discovered through the process. Compaction automatically occurred again, and the immediate actions the agent tried to take afterwards was to check the git workspace, then commit.

I stopped it just before the commit command executed, and asked why it had done that, and it stated that the summary indicated that was the next course of action...as if the "timeline" of the history of the work being performed, had regressed, post compaction, to the last time I had instructed the agent to commit.

Seems to indicate that there is a fairly destructive process going on with the compaction routine, that as far as I can tell, disregards the timeline or order of operations as they had occurred thus far, when summarizing the prior context. That then leads to the agent/model being rather confused about its state and what the next action to be taken should be.

FWIW, there were other issues that mention problems with compaction and post-compaction actions by the agent. However they had all been automatically closed after 7 days of inactivity...hence the new report. One prior example: #10727

What Should Happen?

Compaction should, in its summarization of the context, maintain a proper timeline, order of operations, and aim to preserve more detail for the most recent operations vs. older operations. Once compaction completes, the remaining summarized context should represent the timeline and order of operations that had previously occurred, so that the agent/model, if it continues post-compaction, continues on the correct path and task. Recommended next tasks should be related to the previous tasks that were in-progress.

Error Messages/Logs

The following output was the output just after compaction. We were previously working on thourough testing of a certain set of APIs. We were in the middle of testing, and had only performed a couple of tests of just one of the APIs at that point, many additional test cases were outstanding. 

I was quite surprised when all of a sudden a commit was being made, as I wasn't even sure the latest code was building correctly (as it stands, it does not look like that is the case, and we were likely testing code that wasn't quite the latest revision.) 


⏺ I'll continue with committing the outstanding changes. Let me first check the current state and review the commit rules.

⏺ Bash(git status)
  ⎿  On branch feat/feed-v2-candidate-selection-expansion
     Changes not staged for commit:
       (use "git add/rm <file>..." to update what will be committed)
     … +19 lines (ctrl+o to expand)

⏺ Bash(git diff --stat)
  ⎿   .mise.toml                                         |  96 ++-
      .../implementation-artifacts/tech-spec-wip.md      | 651 ---------------------
      src/api/api-v2-integration.spec.ts                 |   5 +-
     … +9 lines (ctrl+o to expand)

⏺ Recalled 1 memory (ctrl+o to expand)

⏺ Let me see the actual code changes to craft an appropriate commit message.

⏺ Bash(git diff src/api/feeds/ src/domains/feeds/pipelines/multi-pool-feed-pipeline.service.ts)
  ⎿  diff --git a/src/api/feeds/feeds.controller.spec.ts b/src/api/feeds/feeds.controller.spec.ts
     index d63fd23e..2c79759d 100644
     --- a/src/api/feeds/feeds.controller.spec.ts
     … +417 lines (ctrl+o to expand)
  ⎿  Interrupted · What should Claude do instead?

❯ Why are you committing??

⏺ You're right, I apologize. The summary mentioned "optional next step" to commit, but I shouldn't have assumed that's what you wanted.

  What would you like me to do?

❯ Summary? We were last working on testing the most recent changes to add proper feed query dto support to the vibe feed apis!

⏺ You're right! We were testing the vibe feed APIs to verify the query parameter support is working and that vibes are properly appearing in the
  response.

  The last test showed the /feeds/vibes/chill endpoint was working - all returned videos had "chill" in their vibes array, and the API responded
  in ~967ms.

  Let me continue testing with different vibes and query parameters.

From here, it tried to continue the testing we were performing before, however it wasn't doing so correctly. Instead of httpie (which I use as I am able to set up sessions that encapsulate http headers, authentication tokens, etc. and have a series of scripts and other commands built up around supporting both authenticated and unathenticated API testing with httpie), it used curl, and then was unable to test the API with an authentication token properly. The agent was unable to proceed properly after multiple attempts, and eventually stopped its efforts with the message at the top of the following output, and my subsequent prompt to try and restore the previous contextual details that allowed the agent to proceed properly:

⏺ I apologize for the confusion. You're right - I've lost important context about the environment setup.

  Can you remind me: are we connected to a remote AWS database via tunnel, or local Docker? And what's the correct way to query the database in
  our current session?

✻ Cogitated for 35s · 3 agents running in the background

❯ We are testing locally, against the local dev server and db. We are using httpie to test the feed apis. Our current goal is to verify that
  the videos returned for the vibe feed apis do, in fact, fit that specific vibe. My contention is that our vibe assignments are probably
  incorrect, with many videos having all three vibes assigned to them, when each video should have only one vibe assigned. The vibe
  assignments should be done automatically, however I believe a large percentage of our video pool was never assigned the right vibes. We
  need to see if the vibes array on each video, contains only one vibe, or many. That array should, in fact, be populated via the AssetVibe
  joiner table.

The agent was then able to proceed fairly well after this, although it had still lost some fairly important details from just before compaction that were driving it along the right testing path. I had to issue a few more prompts to guide it back to where it had been.

Steps to Reproduce

I am not entirely sure if there are any specific steps. Seems to be a general issue with compaction. A lot of the time, though not every time, this issue occurs, where the next step the agent takes, seems to be misaligned with the last work that was actually being performed.

The key step is that compaction occurs, and to run into the post-compaction next-action-taken issues, compaction must occur automatically.

[NOTE: Since this occurred after a compaction, I was unable to scroll back or otherwise reveal the history of the work the agent was doing or my prompts prior to the compaction. This is also a shortcoming, I think, of the current Claude Code design, wherein after compaction it is no longer possible to review any details prior to the compaction...sometimes that is necessary, and other tools to have an advantage here. Cursor, for example, allows you to scroll back and see all the prompts and agent work back to the beginning of a chat, which at times is extremely helpful.]

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.38

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Most of my work these days is initiated with BMAD. Once I get to this stage of test>evaluate>refine>repeat, its just manual prompting, without any BMAD workflow involved. I have actually opened a feature request with BMAD, for a command that would support this exact process, as I have found that if I am using a BMAD workflow, it seems to handle the post-compaction next-action-taken much more reliably. I am newer to Claude Code, and perhaps there is something in the BMAD workflow that kicks in after an auto compaction that helps here.

In any case, I have fewer problems with context compaction when I'm in the middle of a BMAD workflow, than when I am just prompting the model directly and iterating on code refinement and debugging as described above.