Repository navigation
Description
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
Plan mode's system prompt uses absolute language that prevents ALL bash commands except read/inspect operations. This blocks legitimate planning activities like:
- Creating/updating GitHub issues via
gh issue create,gh pr create - Creating/updating GitLab issues via
glab issue create,glab mr create - Generating and committing planning diagrams or documentation artifacts
This forces users into build mode for these activities, which often leads to the agent executing code changes prematurely before planning is complete.
Problematic responses in plan mode
When asked to create a GitHub issue or GitLab ticket in plan mode, the agent responds with variations of:
"I'm in plan mode and cannot execute commands. I can only read and analyze. Please switch to build mode to create the issue."
"Plan mode restricts me to read-only operations. Creating a GitHub issue requires running
gh issue create, which I cannot do in this mode."
This happens because the system prompt (packages/opencode/src/session/prompt/plan.txt) states:
STRICTLY FORBIDDEN: ANY file edits, modifications, or system changes.
Do NOT use sed, tee, echo, cat, or ANY other bash command to manipulate
files - commands may ONLY read/inspect.
...ZERO exceptions.
And the ## Important section reinforces:
you MUST NOT make any edits, run any non-readonly tools (including
changing configs or making commits), or otherwise make any changes
to the system.
The experimental plan prompt (prompt.ts:279) has the same restriction: "run any non-readonly tools (including changing configs or making commits)"
Root cause
The plan agent's bash tool is NOT hard-denied in the permission config (agent.ts:124-146) — it inherits "allow" from defaults. The model's refusal is caused entirely by the system prompt's absolutist language, which makes no distinction between "modifying source code" and "managing project tickets."
Recommended fix (3 files, ~35 lines changed)
-
packages/opencode/src/session/prompt/plan.txt— Reframe restrictions from "ALL commands" to "source code modifications." Add an explicit "Allowed planning activities" section listing issue/ticket management (gh,glab), PR/MR management, documentation artifacts, and project queries. -
packages/opencode/src/session/prompt.ts(experimental plan prompt) — Same distinction: restrict source code edits, explicitly permit planning CLI tools. -
packages/opencode/src/agent/agent.ts— Add explicitbash: { "gh *": "allow", "glab *": "allow" }permission rules to the plan agent config, making the intent unambiguous at the permission layer (not just prompt).
Benefits
- Users can stay in plan mode for the entire planning workflow (research → create tickets → write specs → create PR) without being forced into build mode
- Source code is still fully protected from modification
- The permission system and the system prompt are aligned in intent
OpenCode version: v1.14.21
OS: macOS (Darwin)
Terminal: Ghostty
Activity
github-actions commentedon Apr 23, 2026
This issue might be a duplicate of existing issues. Please check:
plan.txt/plan mode system prompt) and propose softening restrictions to allow certain operations while keeping source code protected. That issue also references the same files (prompt/plan.txt,prompt.ts) and proposes making the read-only constraint configurable or context-aware.manfreed commentedon Jun 14, 2026
Please don't. I don't want my planning agent to execute any sort of commands, especially not those that can make irreversible changes to remote systems.
This is a really bad solution.
What is it exactly that you want to fix? Why is it not good enough to clearly tell your agent that the plan is to build a plan, and execution is persisting the plan? I do that all the time and I never had any problem with it starting to implement it.
I'm already not happy that ANY sort of bash command execution is possible in planning mode. Agents can and will make mistakes, and planning is about collecting information, not outputting. The only output is the plan itself, but even if you want a solution where that plan ends up on a remote service, there could be so much better solutions than giving an agent full access to certain CLI tools and the ability to execute a possibly dangerous commands.
If you really need your agent to access existing tickets to do the planning, whitelisting gh and glab fully is still not a good solution. There are MCPs that can give finetuned access, and maybe what we need is a set of configuration that allows certain tools to be accessed during planning.
github-actions commentedon Aug 14, 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.