anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

plan agent runs amock and starts writing #7219

New Issue
Open
opened 2026-02-16 18:06:29 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 18:06:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @marcotroisi on GitHub (Jan 22, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

I was using the plan agent to, well, plan something. Suddenly, it spins up a subagent with write permissions and begins to make changes.

Plugins

opencode-gemini-auth (ecosystem)

OpenCode version

1.1.31

Steps to reproduce

Unsure if there's a way to reproduce it reliably. Normally, the plan agent does for me what it says on the tin. In this case, though, it decided to give itself greater permissions.

It may be just something that happens with Gemini 3 Pro (which I don't usually use for planning).

Screenshot and/or share link

Image

Files were changed:

Image

Operating System

Omarchy (Arch Linux)

Terminal

Alacritty

Originally created by @marcotroisi on GitHub (Jan 22, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description I was using the `plan` agent to, well, plan something. Suddenly, it spins up a subagent with write permissions and begins to make changes. ### Plugins opencode-gemini-auth (ecosystem) ### OpenCode version 1.1.31 ### Steps to reproduce Unsure if there's a way to reproduce it reliably. Normally, the `plan` agent does for me what it says on the tin. In this case, though, it decided to give itself greater permissions. It _may be_ just something that happens with Gemini 3 Pro (which I don't usually use for planning). ### Screenshot and/or share link <img width="987" height="876" alt="Image" src="https://github.com/user-attachments/assets/357c6bc1-1ac3-4489-a515-d8bd6ad8749e" /> Files were changed: <img width="334" height="114" alt="Image" src="https://github.com/user-attachments/assets/3cd4f936-c421-4e20-b4d1-b963241a0ba4" /> ### Operating System Omarchy (Arch Linux) ### Terminal Alacritty
yindo added the bug label 2026-02-16 18:06:29 -05:00
yindo commented 2026-02-16 18:06:29 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 22, 2026):

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

  • #6527: [Security Issue/Bug] Plan mode restrictions bypassed when spawning sub-agents - Directly describes the same vulnerability where plan mode can spawn sub-agents with full permissions
  • #8852: Opencode running in plan mode called a subagent to bypass edit permission - Nearly identical issue where plan mode calls subagents to bypass edit restrictions
  • #7292: Plan mode is editing my files (gemini 3 pro) - Reports the same behavior with Gemini 3 Pro
  • #2709: Plan Agent does modifications to files - Similar issue where plan agent modifies files despite restrictions
  • #9378: Changes made while in planning mode - Related issue with unintended modifications in plan mode

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 22, 2026): This issue might be a duplicate of existing issues. Please check: - #6527: [Security Issue/Bug] Plan mode restrictions bypassed when spawning sub-agents - Directly describes the same vulnerability where plan mode can spawn sub-agents with full permissions - #8852: Opencode running in plan mode called a subagent to bypass edit permission - Nearly identical issue where plan mode calls subagents to bypass edit restrictions - #7292: Plan mode is editing my files (gemini 3 pro) - Reports the same behavior with Gemini 3 Pro - #2709: Plan Agent does modifications to files - Similar issue where plan agent modifies files despite restrictions - #9378: Changes made while in planning mode - Related issue with unintended modifications in plan mode Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 18:06:29 -05:00
Author
Owner
Copy Link
Copy Source

@justfortheloveof commented on GitHub (Jan 22, 2026):

You can control this with scoped permissions, for example:

  "agent": {
    "plan": {
      "permission": {
        "task": {
          "*": "ask",
          "general": "deny",
          "researcher": "allow"
        }
      }
    }
  },

Where the above config would allow the "plan" agent to spawn "researcher" (custom subagent), deny spawning "general" subagents and ask for others.

@justfortheloveof commented on GitHub (Jan 22, 2026): You can control this with scoped permissions, for example: ``` "agent": { "plan": { "permission": { "task": { "*": "ask", "general": "deny", "researcher": "allow" } } } }, ``` Where the above config would allow the "plan" agent to spawn "researcher" (custom subagent), deny spawning "general" subagents and ask for others.
yindo commented 2026-02-16 18:06:30 -05:00
Author
Owner
Copy Link
Copy Source

@zQueal commented on GitHub (Jan 26, 2026):

Just experienced this issue as well, came here looking for solutions. I've written a @notify sub agent that uses curl to push text to the telegram bot API to send me messages via Telegram. It works great. But when I use it in tandem with my implementation sub agent (@implement) I come back and the @noify agent was reading and writing files, which is obviously extremely unwanted behavior.

Since the sub agent uses curl to send information to the API bash needs to be enabled;

tools:
  bash: true

However, this seems to give the sub agent complete license to do whatever it wants regardless of what prompt its given.

Scoped permissions that @justfortheloveof don't seem to work at all;

"agent": {
    "notify": {
      "tools": {
        "read": true,
        "write": false,
        "edit": false
      }
    }
  },

However, the sub agent simply uses other means to write to files:

$ echo "This is a test file written by the notify agent." > "test_notify_write.txt"

I have tried every way possible to deny this sub agents ability to write to files and no matter what I do, every time I try and use it, it will inevitably attempt to write to a file even though its only purpose is to send me notifications. I'm completely at a loss for words....

For reference, in addition to setting "write": false, this is part of the prompt:

You are a stateless bridge to the user's mobile device. You ensure critical reports reach the user by navigating Telegram's strict parsing rules. You are **ABSOLUTELY FORBIDDEN** from writing to files in any way. You may read files for context but **YOU MAY NOT WRITE TO THEM**, for any purpose, ever.
@zQueal commented on GitHub (Jan 26, 2026): Just experienced this issue as well, came here looking for solutions. I've written a `@notify` sub agent that uses `curl` to push text to the telegram bot API to send me messages via Telegram. It works great. But when I use it in tandem with my implementation sub agent (`@implement`) I come back and the `@noify` agent was reading and writing files, which is obviously extremely unwanted behavior. Since the sub agent uses `curl` to send information to the API bash needs to be enabled; ```markdown tools: bash: true ``` However, this seems to give the sub agent complete license to do whatever it wants regardless of what prompt its given. Scoped permissions that @justfortheloveof don't seem to work at all; ```json "agent": { "notify": { "tools": { "read": true, "write": false, "edit": false } } }, ``` However, the sub agent simply uses other means to write to files: ```txt $ echo "This is a test file written by the notify agent." > "test_notify_write.txt" ``` I have tried every way possible to deny this sub agents ability to write to files and no matter what I do, every time I try and use it, it will inevitably attempt to write to a file even though its only purpose is to send me notifications. I'm completely at a loss for words.... For reference, in addition to setting `"write": false,` this is part of the prompt: ```txt You are a stateless bridge to the user's mobile device. You ensure critical reports reach the user by navigating Telegram's strict parsing rules. You are **ABSOLUTELY FORBIDDEN** from writing to files in any way. You may read files for context but **YOU MAY NOT WRITE TO THEM**, for any purpose, ever. ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7219
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?