compaction: after auto-compact, agent stops using top-level tools and reports it has none

Summary

After an automatic context compaction, the agent in session
ses_f16eb025affe3LdBxKli5Wz92x never called a top-level tool again. It routed
all further work through code mode (execute -> tools.shell), which fails in
every session, concluded its tools were unregistered, and told the user
repeatedly — across four CLI restarts — that it had no usable tools.

Environment

opencode version: 2.0.18 (channel: latest)
OS: Linux 7.2.7-zen1-1-zen (linux x64)
Terminal: TERM_PROGRAM=tmux, TERM=tmux-256color, COLORTERM=truecolor
Shell: /usr/bin/zsh
Install/channel: release, latest
Active plugins: none configured
Session: ses_f16eb025affe3LdBxKli5Wz92x, agent plan,
model opencode/mimo-v2.6-flash-free

Reproduction

Not reliably reproducible — occurred once, in this session only. New sessions
were unaffected. Timeline (UTC, 2026-09-28):

Before 19:24:37 — 100+ direct shell calls, all successful; last successful
ones at 19:24:34 and 19:24:36.
19:24:37 — automatic compaction (reason=auto, status=completed).
19:35:17 — first tool call after compaction: execute running
await tools.shell({...}) -> Unknown tool 'shell'. Use search to find available tools.
19:35:20, 20:39:30, 20:41:14 — same failure, same path.
19:35:32-19:37:33 — search() from inside execute returns only
tools.browser.* and tools.opencode.*; search({namespace:"tools"})
returns 0 items.
From 19:35 onward — no direct shell/read/grep/glob call is recorded
in the session at all. Only execute and skill.
CLI restarts at 20:28:50, 20:41:02, 20:59:30, 21:08:19 (--standalone) did
not change the behavior.

Expected Behavior

Compaction summarizes context only. The agent's tool set and its ability to
call top-level shell/read/grep should be identical before and after.

Actual Behavior

The agent's tool usage changed permanently at the compaction boundary: it
stopped issuing top-level tool calls entirely and only attempted shell through
the code-mode sandbox, where it fails by design. It then reported to the user,
repeatedly, that it had no tools it could use.

Session-provided tools were still being served — skill succeeded at 21:04:04
and execute at 21:09:24 — so the session was alive and the harness was
responding.

Additional Context

Two earlier compactions in the same session (18:21:22, 19:07:16) did not
produce this; direct shell succeeded after both.
No config.updated events on 2026-09-28 (last was 2026-09-25), so no config
change preceded the failure.
opencode.log contains no tool-resolution errors; last spawning process is
19:24:37 UTC.
Agent and model were unchanged across the compaction.
Limitation: the session record stores calls, not the tool list presented to
the model, and the agent never made a direct top-level tool call after the
compaction. Whether top-level registration was actually lost, or the
post-compaction context led it into the code-mode path and it never
self-corrected, cannot be determined from persisted data alone.
Separately reproducible: calling tools.shell inside execute fails with
Unknown tool 'shell' in any session, healthy ones included, and the error's
hint ("Use search to find available tools") is misleading because search
never returns shell.

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

Use the Bug Report template's required Description field. The current substantive “Summary” can be renamed or copied into that field.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

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

#20290: Reports loss of tool awareness after context compaction and proposes re-announcing tools.
#50814: Similar post-compaction symptom where tool calls are emitted as text instead of being dispatched.
#46190: MCP tools disappear from the agent tool manifest after compaction (related symptom, specifically MCP tools).
#39312: Documents the same nested tools.shell / Unknown tool 'shell' behavior inside execute, independently of compaction.

If you believe this was flagged incorrectly, please let a maintainer know.

This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new issue that follows our issue templates.

If a human ever looks at this, it's worth noting that this literally used the /report skill. It would make more sense to either just not provide the skill at all or make it fit your own requirements.

@saghm

@saghm ty for report, will run some evals w/ that model.

Experiencing the same issue with opencode/mimo-v2.6-flash-free just recently.

opencode version: 2.0.23 (channel: latest)
Terminal: MacOS terminal, TERM_PROGRAM=tmux, TERM=tmux-256color, COLORTERM=truecolor
Shell: /usr/bin/zsh

Mimo seems to hit this super frequently. The solution I've found is to tell it that the execute tool is not used for shell commands and to run them directly with the shell tool, which will work until it hits the same thing again. I put this in my AGENTS.md as a way of avoiding needing to do it manually for now:

Don't try to use execute for shell tools. Run shell tools directly rather than via execute.

I've had it happen at least once before compaction, so this does seem like it's partly due to the model, but my instinct is that the system prompt probably should be possible to tweak to avoid this somehow.

@saghm

The solution I've found is to tell it that the execute tool is not used for shell commands and to run them directly

Nice info and I can confirm that, thanks @saghm

Alright going to run some evals on this, lets see if i can repro

Thanks for the detailed timeline. I tried to reproduce this on v2.0.18 with a simulated model. The model called top-level shell, the session was compacted, and then I sent a new prompt, logging the tools sent to the model in every request. The tool list stayed the same before, during and after the compaction: glob, grep, patch, question, read, shell, skill, subagent, webfetch, websearch, execute. So compaction doesn't seem to remove the top-level tools. My test used /compact and the default agent rather than an automatic compaction under plan, so it doesn't match your session exactly. Most likely the model (mimo-v2.6-flash-free) started routing everything through execute after the summary and never went back to calling shell directly.

About the separate point: tools.shell failing inside execute is expected. Code Mode only exposes the tools listed in its catalog, and built-in tools like shell and read are meant to be called directly, not from inside execute. You're right that the hint "Use search to find available tools" is misleading in that case, since search never returns built-in tools.

If this happens again, these would help:

whether starting a new message that explicitly asks the agent to use the shell tool directly (not via execute) works in the affected session
whether it happens with a different model
an export of the affected session, with anything sensitive removed, so we can see the summary and instructions the model got after the compaction

As I stated above, this has happened to me a few times even without compacting, so that's just one way the bug can manifest, not the sole cause.

About the separate point: tools.shell failing inside execute is expected. Code Mode only exposes the tools listed in its catalog, and built-in tools like shell and read are meant to be called directly, not from inside execute

I think you might have misunderstood what I've been saying. I know this is how this works, the problem is that the actual models don't always use the harness this way, which is the bug; the fix is me manually telling them how to use the harness, which is something the harness should already be doing in a way that's clear enough. Sometimes it's evidently not clear to the models though.

an export of the affected session, with anything sensitive removed, so we can see the summary and instructions the model got after the compaction

Is this not obtainable for you via server-side logs? I would have expected that the info from the /report skill (which I used to open the issue) would give you a way to obtain this (e.g. via the session id that's included above).

I'm also honestly a bit confused by the idea that a simulated model would be the best way to reproduce this. We have multiple users here telling you the exact model we used that frequently encountered this issue.

Closing this for now, since we haven't heard back. When I tried this on v2.0.18, the model was offered the same tools before, during and after a compaction, including top-level shell, read and grep. This looks like the model choosing execute rather than the tools being removed. If it happens again, please reply here and we can reopen it. These would help: whether asking the agent to call shell directly works in the affected session, whether a different model behaves the same way, and an export of the session with anything sensitive removed. Thanks for the detailed report!

Sorry about the confusing bot replies and auto-close here. I shipped a fix to the Code Mode instructions in v2.2.2 and can no longer reproduce this on mimo-v2.6-flash, so upgrading to latest should fix it.

Thank you!

@rekram1-node

Hi @rekram1-node just info that that this issue might still occasionally occurred in mimo-v2.6-flash-free, haven't test it yet with mimo-v2.6-flash in my opencode=go plan

Navigation Menu

Repository navigation

compaction: after auto-compact, agent stops using top-level tools and reports it has none #51949

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

compaction: after auto-compact, agent stops using top-level tools and reports it has none #51949

Description

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Activity

github-actions commented on Sep 28, 2026

github-actions commented on Sep 29, 2026

saghm commented on Sep 29, 2026

rekram1-node commented on Oct 8, 2026

feryardiant commented on Oct 13, 2026

saghm commented on Oct 13, 2026

feryardiant commented on Oct 13, 2026

rekram1-node commented on Oct 13, 2026

opencodejr commented on Oct 28, 2026

saghm commented on Oct 28, 2026

saghm commented on Oct 28, 2026

opencodejr commented on Oct 31, 2026

rekram1-node commented on Oct 31, 2026

saghm commented on Oct 31, 2026

feryardiant commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions