/compact causes the agent to continue unexpectedly

[fubar-coder]

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 /compact triggers, 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:

1. The agent is in the middle of an active task -> continuing makes sense.
2. 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

1. Start a new opencode session.
2. Begin a longer, multi-step task (e.g. a spec-driven change or refactor using openspec).
3. Interact with the agent for several turns until the context window is close to full.
4. Ask a question that does not imply further action (e.g. a clarification or confirmation).
5. Let the agent answer the question.
6. Observe that /compact is triggered automatically shortly after.
7. 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

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Auto-compaction infinite loop when assistant ended its turn (finish !== tool-calls) #15533: Describes the same root cause — auto-compaction unconditionally injects a synthetic "Continue..." message even when the assistant has naturally ended its turn (finish === "stop"), causing the agent to continue working instead of waiting for user input. The root cause and expected fix described there appear to be the same issue you're experiencing.
• Stops after compaction #13217: Related — agent stops mid-task after compaction (the inverse behavior, but same underlying compaction/state-tracking problem).

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]

Auto-compaction infinite loop when assistant ended its turn (finish !== tool-calls) #15533: Describes the same root cause — auto-compaction unconditionally injects a synthetic "Continue..." message even when the assistant has naturally ended its turn (finish === "stop"), causing the agent to continue working instead of waiting for user input. The root cause and expected fix described there appear to be the same issue you're experiencing.

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.

Stops after compaction #13217: Related — agent stops mid-task after compaction (the inverse behavior, but same underlying compaction/state-tracking problem).

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:

• After /compact, the agent seems to lose the distinction between “actively working on a task” and “waiting for user input”.
• In cases where compaction happens right after answering a question, the agent often resumes remaining work automatically, even though no further action was requested.
• This suggests that compaction is currently context-driven, but not aware of the agent’s current task or wait state.
• From a user perspective, it would be important for /compact to preserve whether the agent was in the middle of a task or had naturally reached a point where it should wait.