Repository navigation
/compact causes the agent to continue unexpectedly #18794
Description
Description
This seems closely related to #13217, but I think there’s an important aspect missing there.
What I’m running into in longer agent/spec-style sessions:
- When
/compacttriggers, the agent often continues with some work automatically. - In many cases, that’s actually not what I want.
There are at least two different states that currently get treated the same:
- The agent is in the middle of an active task -> continuing makes sense.
- The agent just answered a question and is waiting for user input -> continuing is wrong.
Issue #13217 focuses on what the agent should continue with after /compact, but the bigger problem (for me) is that the agent doesn’t know whether it should continue at all.
After a compact, the implicit “wait for user” state is often lost, which leads to:
- unfinished tasks being abandoned
- answered questions immediately followed by unrelated work
- the feeling that the agent is acting without an explicit prompt
This seems less like a UX issue and more like missing task / wait-state semantics around /compact.
I don’t have a concrete implementation proposal here, but I wanted to point out that “continue working” is not always the correct default after compaction.
Plugins
No response
OpenCode version
1.3.0
Steps to reproduce
- Start a new opencode session.
- Begin a longer, multi-step task (e.g. a spec-driven change or refactor using openspec).
- Interact with the agent for several turns until the context window is close to full.
- Ask a question that does not imply further action (e.g. a clarification or confirmation).
- Let the agent answer the question.
- Observe that
/compactis triggered automatically shortly after. - After compaction, observe that the agent continues working on unrelated or previous tasks instead of waiting for further user input.
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
Windows Terminal
Activity
github-actions commentedon Mar 23, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is specifically about the agent continuing when it shouldn't (rather than stopping when it should), #15533 is likely the most direct match.
fubar-coder commentedon Mar 23, 2026
This is related, but I’m not seeing an infinite loop. What happens here is a single, unwanted continuation after compaction.
In my case, compaction often runs right before / during / after the agent answers a simple question. I only want the answer - not for the agent to resume previously open tasks.
That issue describes the agent stopping mid-task. Here it’s usually the opposite: after compaction, the agent notices remaining tasks and continues working, even though no further action was requested.
The common theme seems to be that after
/compact, the implicit “wait for user input” state isn’t reliably preserved.Some thoughts I have about this issue:
/compact, the agent seems to lose the distinction between “actively working on a task” and “waiting for user input”./compactto preserve whether the agent was in the middle of a task or had naturally reached a point where it should wait.thekorsen commentedon Mar 23, 2026
Came here looking into this myself, I'm encountering the same issue on a fresh install. Serving the LLM locally via oMLX, occurs on various models (Qwen3.5 27b, 34b, 122b). Occurs on the agents build, plan, and a new simple primary agent I created.
fix(session): preserve wait-for-user state after compaction (anomalyc…
github-actions commentedon Jul 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.