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

BUG: Overriding built-in agents, doesn't allow overriding permissions #2363

New Issue
Open
opened 2026-02-16 17:35:20 -05:00 by yindo · 12 comments
yindo commented 2026-02-16 17:35:20 -05:00
Owner
Copy Link
Copy Source

Originally created by @oribarilan on GitHub (Oct 30, 2025).

Originally assigned to: @rekram1-node on GitHub.

Description

I am overriding the built-in agents (e.g., using agent/plan.md) which although not documented, it successfully catches my new prompt. However, I want this agent to be able to write markdown files, but even though i am properly setting permissions, agent qoutes:

"CRITICAL: Plan mode ACTIVE - you are in READ-ONLY phase. STRICTLY
FORBIDDEN: ANY file edits, modifications, or system changes...

Expected behavior in my opinion is that if another definition of a plan agent exists, it should bypass the original plan agent entirely.

OpenCode version

0.15.29 (latest)

Steps to reproduce

  1. define plan.md agent
  2. give it write permissions (e.g., to a .md files, example below)
  3. give it a custom prompt
  4. ask it to generate a file and see your prompt is used but permissions are ignored

permission example:

permissions:
  write:
    ".plan/*": allow
    "*": deny
  edit:
    ".plan/*": allow
    "*": deny

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Originally created by @oribarilan on GitHub (Oct 30, 2025). Originally assigned to: @rekram1-node on GitHub. ### Description I am overriding the built-in agents (e.g., using agent/plan.md) which although not documented, it successfully catches my new prompt. However, I want this agent to be able to write markdown files, but even though i am properly setting permissions, agent qoutes: > "CRITICAL: Plan mode ACTIVE - you are in READ-ONLY phase. STRICTLY > FORBIDDEN: ANY file edits, modifications, or system changes... Expected behavior in my opinion is that if another definition of a plan agent exists, it should bypass the original plan agent entirely. ### OpenCode version 0.15.29 (latest) ### Steps to reproduce 1. define plan.md agent 2. give it write permissions (e.g., to a .md files, example below) 3. give it a custom prompt 4. ask it to generate a file and see your prompt is used but permissions are ignored permission example: ``` permissions: write: ".plan/*": allow "*": deny edit: ".plan/*": allow "*": deny ``` ### Screenshot and/or share link _No response_ ### Operating System _No response_ ### Terminal _No response_
yindo added the bug label 2026-02-16 17:35:20 -05:00
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 30, 2025):

Ahh this is something I stupidly didn't think about lol

The prompt reminder we give it says it can't edit files, we should probably adjust it to tell the agent it's own permissions and encourage it to obey them.

Then we can use some basic templating to fix this

@rekram1-node commented on GitHub (Oct 30, 2025): Ahh this is something I stupidly didn't think about lol The prompt reminder we give it says it can't edit files, we should probably adjust it to tell the agent it's own permissions and encourage it to obey them. Then we can use some basic templating to fix this
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@oribarilan commented on GitHub (Oct 30, 2025):

why not allowing to override built-in agent entirely? Instead of messing with carry-over from built-in spec to a custom agent with the same name, we can just allow a complete override.
So, if the user defines a "plan" agent, the built-in one become obsolete, and the PLAN agent that appears points to the custom agent entirely.
Sounds simpler and more pragmatic

@oribarilan commented on GitHub (Oct 30, 2025): why not allowing to override built-in agent entirely? Instead of messing with carry-over from built-in spec to a custom agent with the same name, we can just allow a complete override. So, if the user defines a "plan" agent, the built-in one become obsolete, and the PLAN agent that appears points to the custom agent entirely. Sounds simpler and more pragmatic
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 30, 2025):

Well you can override everything for the agent, but we also inject <system-reminders> that are not part of the system prompt

That is why you see this behavior

So perhaps we can expose that in some way instead

@rekram1-node commented on GitHub (Oct 30, 2025): Well you can override everything for the agent, but we also inject `<system-reminders>` that are not part of the system prompt That is why you see this behavior So perhaps we can expose that in some way instead
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@oribarilan commented on GitHub (Oct 30, 2025):

oh interesting. i wonder why these are not implemented simply as permissions (that can be overriden). sounds like a non-trivial decision so I'll just rename my agent to something other than plan for now :)

is there anyway to disable a built-in agent?

@oribarilan commented on GitHub (Oct 30, 2025): oh interesting. i wonder why these are not implemented simply as permissions (that can be overriden). sounds like a non-trivial decision so I'll just rename my agent to something other than `plan` for now :) is there anyway to disable a built-in agent?
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 30, 2025):

is there anyway to disable a built-in agent?

Not rn no

i wonder why these are not implemented simply as permissions

They are implemented as permissions but there are system reminders too (essentially just hidden user messages), because we don't want the agent to try to abuse the tools it does have to get around the idea of being in "plan" mode

I don't think it is non-trivial to add some way to customize around this, just probably not the highest priority atm

@rekram1-node commented on GitHub (Oct 30, 2025): > is there anyway to disable a built-in agent? Not rn no > i wonder why these are not implemented simply as permissions They are implemented as permissions but there are system reminders too (essentially just hidden user messages), because we don't want the agent to try to abuse the tools it does have to get around the idea of being in "plan" mode I don't think it is non-trivial to add some way to customize around this, just probably not the highest priority atm
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@ferrao commented on GitHub (Oct 30, 2025):

... so I'll just rename my agent to something other than plan for now :)

Exactly what I did, so I now have a plan and a planner agent ;)
It's not the worse thing in the world, but of course simply being able to disable the built in agents would make it cleaner.

@ferrao commented on GitHub (Oct 30, 2025): >... so I'll just rename my agent to something other than `plan` for now :) Exactly what I did, so I now have a `plan` and a `planner` agent ;) It's not the worse thing in the world, but of course simply being able to disable the built in agents would make it cleaner.
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@oribarilan commented on GitHub (Oct 30, 2025):

@rekram1-node if you want to spec a solution i can try to tackle it
(disable built-in agent, avoid plan system reminders if user has plan agent, etc.)

@oribarilan commented on GitHub (Oct 30, 2025): @rekram1-node if you want to spec a solution i can try to tackle it (disable built-in agent, avoid plan system reminders if user has plan agent, etc.)
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 30, 2025):

the system reminder may need to be thought out a little bit just to see what makes sense but disabled would be fine, maybe add a disabled field to an agent definition similar to how lsp and formatters have it defined

@rekram1-node commented on GitHub (Oct 30, 2025): the system reminder may need to be thought out a little bit just to see what makes sense but disabled would be fine, maybe add a disabled field to an agent definition similar to how lsp and formatters have it defined
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@oribarilan commented on GitHub (Oct 31, 2025):

sounds good. I will take a shot at it, after my currently open PR is resolved :) (#3580)

@oribarilan commented on GitHub (Oct 31, 2025): sounds good. I will take a shot at it, after my currently open PR is resolved :) (#3580)
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@gw0 commented on GitHub (Nov 13, 2025):

is there anyway to disable a built-in agent?

Not rn no

In OpenCode 1.0.61 one can disable an built-in agent (https://opencode.ai/docs/agents/#disable), but it is still not possible to reuse its name or override it with the agent markdown definition.

I have a feeling everything would be simpler if built-in agents would also be defined with the agent markdown definition instead of with code, then overrides could be supported at the file-loading level.

@gw0 commented on GitHub (Nov 13, 2025): > > is there anyway to disable a built-in agent? > > Not rn no In OpenCode 1.0.61 one can disable an built-in agent (https://opencode.ai/docs/agents/#disable), but it is still not possible to reuse its name or override it with the agent markdown definition. I have a feeling everything would be simpler if built-in agents would also be defined with the agent markdown definition instead of with code, then overrides could be supported at the file-loading level.
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@mintchaos commented on GitHub (Jan 6, 2026):

I ran into some unexpected behavior around this. I added the atlassian mcp server and wanted to use the built in plan agent to plan out some new tickets with some back and forth. But the plan agent just went ahead and made the ticket right away.

Which now that I know more makes sense because nothing in the default perms denys it from using mcp calls.

I think I could fix it by adding something like this but that doesn't help if I can't override permissions easily.

"tools": {
    "atlassian*": false,
    "atlassian_getJira*": true
  }

Furthermore when I asked it to update the ticket after some further planning it had an issue with the mcp calls and then just went ahead and made the changes to the codebase while still in the plan agent. Which was unexpected. This was however on v1.0.220 as I didn't realize that homebrew didn't have the latest. I've since updated.

I do wonder if it'd be best to make some jira specific subagents and give them structured perms and prompts.

@mintchaos commented on GitHub (Jan 6, 2026): I ran into some unexpected behavior around this. I added the atlassian mcp server and wanted to use the built in plan agent to plan out some new tickets with some back and forth. But the plan agent just went ahead and made the ticket right away. Which now that I know more makes sense because nothing in the default perms denys it from using mcp calls. I _think_ I could fix it by adding something like this but that doesn't help if I can't override permissions easily. ```json "tools": { "atlassian*": false, "atlassian_getJira*": true } ``` Furthermore when I asked it to update the ticket after some further planning it had an issue with the mcp calls and then just went ahead and made the changes to the codebase while still in the plan agent. Which was unexpected. This was however on `v1.0.220` as I didn't realize that homebrew didn't have the latest. I've since updated. I do wonder if it'd be best to make some jira specific subagents and give them structured perms and prompts.
yindo commented 2026-02-16 17:35:21 -05:00
Author
Owner
Copy Link
Copy Source

@estenp commented on GitHub (Feb 8, 2026):

Yeah it's annoying the solution here is to just disable the built in because a) you can't unreserve it's name and b) it doesn't track with the docs which imply over and over you can override the built in's via json or markdown by naming the agent config the same as the built in.

https://opencode.ai/docs/agents/#configure

If disabling and renaming built ins is the solution for the foreseeable future the docs should probably be updated because it's all quite misleading.

Fwiw in my testing:

  1. using opencode.json, and overriding "build" to disable writes did not stop it from writing.
  2. using opencode.json, and overriding "plan" to enable writes did not allow it to write.
  3. using .opencode/agents/build.md with write disabled does disable writes.
  4. using .opencode/agents/plan.md with write enabled still does not allow writes.
@estenp commented on GitHub (Feb 8, 2026): Yeah it's annoying the solution here is to just disable the built in because a) you can't unreserve it's name and b) it doesn't track with the docs which imply over and over you can override the built in's via json or markdown by naming the agent config the same as the built in. https://opencode.ai/docs/agents/#configure If disabling and renaming built ins is the solution for the foreseeable future the docs should probably be updated because it's all quite misleading. Fwiw in my testing: 1. using `opencode.json`, and overriding "build" to disable writes did not stop it from writing. 2. using `opencode.json`, and overriding "plan" to enable writes did not allow it to write. 3. using `.opencode/agents/build.md` with write disabled _does_ disable writes. 4. using `.opencode/agents/plan.md` with write enabled still does not allow writes.
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#2363
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?