Repository navigation
Ignored Plan Mode in Opencode V2 #40778
Description
Description
/report uses gh, or tried - I don't have that - hope this is enough. Why does it say 1.17? It's definitely v2.
Side note I have hundreds of millions of tokens passed through V1, tool calls seemed blocked in that version in plan mode...?
Summary
Agent continued implementing code changes while plan mode was active, instead of only producing a plan for approval.
Environment
- opencode version: 1.17.18 (skill snapshot also reported 0.0.0-next-16881)
- OS: Linux 7.1.2-dist aarch64 (
Linux arm-server 7.1.2-dist #1 SMP PREEMPT_DYNAMIC Fri Jul 3 13:58:16 EDT 2026) - Terminal: TERM_PROGRAM=tmux, TERM=xterm-256color, COLORTERM=truecolor
- Shell: /bin/bash
- Install/channel: next (per skill snapshot); local
opencode --version→ 1.17.18 - Active plugins: none found in workspace config
Reproduction
- Start a coding session on a git repo with plan mode enabled.
- Ask for a multi-file refactor (rename modules, add new module, stub APIs).
- Observe the agent begins
mv, edits, and implementation instead of stopping at a plan.
Expected Behavior
In plan mode, the agent should only research and present a plan, then wait for approval before any file changes or implementing shell commands.
Actual Behavior
Agent started executing the work: renamed handles.rs → ihandle.rs, bind.rs → ihandle_stmt.rs, rewrote imports/mod.rs, and began further implementation. User had to interrupt with “Hey you're in plan mode lol”. Partial uncommitted renames were left in the tree.
Additional Context
- Workspace: Rust project (
rs-odbc-drv); session involved ODBC driver module layout. - Frequency: at least once in this session (consistently for that request until interrupted).
- User intent was design/plan for renames +
ihandle_desc+SQLSetDescRecstub; not immediate implementation. - Related git state after interrupt included deleted
handles.rs, untrackedihandle.rs/ihandle_stmt.rs, modified imports — i.e. half-applied rename.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon Aug 6, 2026
This issue might be a duplicate of existing issues. Please check:
CruelAddict commentedon Aug 8, 2026
session-04d6e562-d662-4354-88a4-1b16cde6c52f.json
This has almost never happened to me prior to v2. I've just tried it and in almost every thread after update it just jumps to apply patches while I expect it to give feedback on my plan
upd: agent has no way of knowing which mode it's in, as stated in #40474 . so the plan agent is basically the same as build agent but with worse tool set
opencode-agent commentedon Aug 11, 2026
Fixed by #41665. Plan now receives explicit model-visible read-only reminders on session creation and agent switches. Edit/write/patch remain in the model context for prompt-cache stability but are rejected at execution with Plan-specific tool errors; shell remains available for read-only planning and is explicitly constrained by the Plan reminder. We will iterate on any concrete counterexamples reported against this behavior.
dylanetaft commentedon Aug 20, 2026
It's fixed
colidyre commentedon Oct 25, 2026
Still reproducible in opencode v2.1.4
Environment:
Description:
While in Plan mode, the agent presented a plan as expected. After I replied with "Ja, das hört sich gut an. Setze das bitte um." ("Yes, that sounds good. Please implement it."), but with more information how exactly to implement it (expecting a more fine-granular plan), the agent broke out of plan mode and proceeded to make file changes and create commits instead of stopping and asking to switch to agent/build mode.
The harness did not enforce plan mode restrictions. No plan-specific tool error was thrown and write/edit operations were allowed to execute despite the system reminder stating that no file changes should be made while in plan mode.
The sentence "Setze das bitte um." ("Please implement it.") appears to have triggered the agent to exit plan mode and begin implementation.
This appears to be the same issue as #40778. The fix from #41665 does not seem to be effective in v2.1.4.