You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Plan mode can execute bash commands that write files, bypassing read-only constraint #28467
The plan agent is documented as a read-only agent for analysis and code exploration that denies file edits by default. However, it can still execute bash commands that write/modify files on the filesystem, effectively bypassing the read-only constraint.
Steps to Reproduce
Start opencode in plan mode
Run a bash command that creates/modifies files (e.g. a Python script that splits a PDF into 231 new files)
The command executes successfully and writes files to disk
Expected Behavior
Plan mode should not be able to modify the filesystem. Either:
Bash commands that write files should be blocked
All bash commands should require explicit user approval before execution
Actual Behavior
Bash commands run without restriction, including commands that create, modify, or delete files.
Environment
OS: Windows 11
opencode version: latest
Suggestion
Consider adding bash ask or bash deny to the plan agent default permissions, or implement filesystem write detection for bash commands in plan mode.
Please review the above issues to see if your report is already covered. If it is, consider adding a comment there with any new information rather than opening a new issue.
This is a strong argument for enforcing read-only at the execution boundary, not only at the planning boundary.
If plan mode is allowed to synthesize bash that can still write files, then the mode contract is advisory rather than real. The clean fix is usually a second gate at command admission time: inspect the resolved command/tool intent, classify it as read/write/network/process control, and block writes regardless of what higher-level mode said.
That also gives you a useful audit trail when someone asks why a command was denied.
Activity
github-actions commentedon May 20, 2026
This issue might be a duplicate of existing issues. Please check:
Please review the above issues to see if your report is already covered. If it is, consider adding a comment there with any new information rather than opening a new issue.
Keesan12 commentedon May 20, 2026
This is a strong argument for enforcing read-only at the execution boundary, not only at the planning boundary.
If plan mode is allowed to synthesize bash that can still write files, then the mode contract is advisory rather than real. The clean fix is usually a second gate at command admission time: inspect the resolved command/tool intent, classify it as read/write/network/process control, and block writes regardless of what higher-level mode said.
That also gives you a useful audit trail when someone asks why a command was denied.
github-actions commentedon Jul 20, 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.