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

[PR #6319] Permission rework #11838

New Issue
Closed
opened 2026-02-16 18:16:46 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:46 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/6319

State: closed
Merged: Yes

Summary

This is a major change that overhauls the permissions system in OpenCode.

Tools Merged into Permission

The tools configuration has been deprecated and merged into the permission field. Previously, you could enable/disable tools like this:

{
  "tools": {
    "bash": true,
    "edit": false
  }
}

Now, this should be configured using permission:

{
  "permission": {
    "bash": "allow",
    "edit": "deny"
  }
}

The old tools config is still supported for backwards compatibility and will be automatically migrated to the permission system.

Granular Permissions with Object Syntax

Permissions now support granular control using an object syntax with pattern matching. When you specify a permission as an object, you can set different rules for different patterns:

{
  "permission": {
    "bash": {
      "npm *": "allow",
      "git *": "allow",
      "rm *": "deny",
      "*": "ask"
    },
    "edit": {
      "*.md": "allow",
      "*.ts": "ask",
      "*": "deny"
    }
  }
}

Each key in the object is a glob pattern that matches against the tool's input, and the value is the action to take:

  • "allow" - automatically approve
  • "deny" - automatically reject
  • "ask" - prompt the user for approval

You can also set a blanket permission using a simple string:

{
  "permission": {
    "bash": "allow",
    "edit": "ask"
  }
}

Or set all permissions at once:

{
  "permission": "allow"
}

Breaking Changes for SDK Users

The permission events have changed significantly. The new PermissionNext module (permission/next.ts) has a different event structure compared to the old Permission module (permission/index.ts):

Old Event Structure (Permission.Event):

  • Updated: { id, type, pattern, sessionID, messageID, callID, message, metadata, time }
  • Replied: { sessionID, permissionID, response }

New Event Structure (PermissionNext.Event):

  • Asked: { id, sessionID, permission, patterns, metadata, always, tool: { messageID, callID } }
  • Replied: { sessionID, requestID, reply }

Key differences:

  • Event name changed from permission.updated to permission.asked
  • type renamed to permission
  • pattern is now patterns (array of strings)
  • message field removed
  • response renamed to reply
  • permissionID renamed to requestID
  • New always field contains patterns that would be approved for future requests if user selects "always"

The reply values are the same: "once", "always", or "reject"

Server Changes

  • New endpoint: POST /permission/:requestID/reply for responding to permission requests
  • Old endpoint POST /session/:sessionID/permissions/:permissionID is now deprecated
  • GET /permission now returns PermissionNext.Request[] instead of Permission.Info[]
  • Added CORS whitelist support via server.cors config option
  • Added Content-Type headers for proxied static assets
  • mDNS service name now includes port for uniqueness

Other Changes

  • Agent tools field is deprecated - use permission instead
  • Agent maxSteps is deprecated - use steps instead
  • Unknown agent properties are now collected into options
  • Mode and plugin globs no longer search subdirectories (simplified to top-level only)
**Original Pull Request:** https://github.com/anomalyco/opencode/pull/6319 **State:** closed **Merged:** Yes --- ## Summary This is a **major change** that overhauls the permissions system in OpenCode. ### Tools Merged into Permission The `tools` configuration has been deprecated and merged into the `permission` field. Previously, you could enable/disable tools like this: ```json { "tools": { "bash": true, "edit": false } } ``` Now, this should be configured using `permission`: ```json { "permission": { "bash": "allow", "edit": "deny" } } ``` The old `tools` config is still supported for backwards compatibility and will be automatically migrated to the permission system. ### Granular Permissions with Object Syntax Permissions now support granular control using an object syntax with pattern matching. When you specify a permission as an object, you can set different rules for different patterns: ```json { "permission": { "bash": { "npm *": "allow", "git *": "allow", "rm *": "deny", "*": "ask" }, "edit": { "*.md": "allow", "*.ts": "ask", "*": "deny" } } } ``` Each key in the object is a glob pattern that matches against the tool's input, and the value is the action to take: - `"allow"` - automatically approve - `"deny"` - automatically reject - `"ask"` - prompt the user for approval You can also set a blanket permission using a simple string: ```json { "permission": { "bash": "allow", "edit": "ask" } } ``` Or set all permissions at once: ```json { "permission": "allow" } ``` ### Breaking Changes for SDK Users The permission events have changed significantly. The new `PermissionNext` module (`permission/next.ts`) has a different event structure compared to the old `Permission` module (`permission/index.ts`): **Old Event Structure (`Permission.Event`):** - `Updated`: `{ id, type, pattern, sessionID, messageID, callID, message, metadata, time }` - `Replied`: `{ sessionID, permissionID, response }` **New Event Structure (`PermissionNext.Event`):** - `Asked`: `{ id, sessionID, permission, patterns, metadata, always, tool: { messageID, callID } }` - `Replied`: `{ sessionID, requestID, reply }` Key differences: - Event name changed from `permission.updated` to `permission.asked` - `type` renamed to `permission` - `pattern` is now `patterns` (array of strings) - `message` field removed - `response` renamed to `reply` - `permissionID` renamed to `requestID` - New `always` field contains patterns that would be approved for future requests if user selects "always" The reply values are the same: `"once"`, `"always"`, or `"reject"` ### Server Changes - New endpoint: `POST /permission/:requestID/reply` for responding to permission requests - Old endpoint `POST /session/:sessionID/permissions/:permissionID` is now deprecated - `GET /permission` now returns `PermissionNext.Request[]` instead of `Permission.Info[]` - Added CORS whitelist support via `server.cors` config option - Added Content-Type headers for proxied static assets - mDNS service name now includes port for uniqueness ### Other Changes - Agent `tools` field is deprecated - use `permission` instead - Agent `maxSteps` is deprecated - use `steps` instead - Unknown agent properties are now collected into `options` - Mode and plugin globs no longer search subdirectories (simplified to top-level only)
yindo added the pull-request label 2026-02-16 18:16:46 -05:00
yindo closed this issue 2026-02-16 18:16:46 -05:00
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 pull-request
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#11838
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?