Skip to content

[FEATURE]: Plan mode should allow planning-related CLI tools (gh, glab, ticket management, diagrams) #23984

Closed as not planned

Description

@MattPark
  • 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)

  1. 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.

  2. packages/opencode/src/session/prompt.ts (experimental plan prompt) — Same distinction: restrict source code edits, explicitly permit planning CLI tools.

  3. packages/opencode/src/agent/agent.ts — Add explicit bash: { "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

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Apr 23, 2026
  2. github-actions commented on Apr 23, 2026

    @github-actions
    Contributor

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

  3. removed
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  4. manfreed commented on Jun 14, 2026

    @manfreed

    Add explicit bash: { "gh *": "allow", "glab *": "allow" } permission rules to the plan agent config

    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.

  5. github-actions commented on Aug 14, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions