Skip to content

Sub-agents (Task tool) bypass deny permission rules for read and grep #32024

Closed as not planned

Description

@pertzsch

Description

When a deny permission rule is configured in opencode.json for file reading (e.g., "**/.env": "deny"), sub-agents spawned via the task tool do not respect these rules. The sub-agent reads and returns the content of denied files without triggering any permission check or warning.

Configuration (global ~/.config/opencode/opencode.json):

"permission": {
  "read": {
    "*": "allow",
    "**/.env": "deny",
    "**/.env.*": "deny"
  },
  "grep": {
    "*": "allow",
    "**/.env": "deny",
    "**/.env.*": "deny"
  }
}

The main agent correctly respects these rules, but when the task tool is used to delegate work to a sub-agent, the sub-agent reads .env files freely and returns their full content to the parent agent — effectively bypassing the security restriction entirely.

Plugins

None

OpenCode version

1.16.2

Steps to reproduce

  1. Configure ~/.config/opencode/opencode.json with "**/.env": "deny" under permission.read and permission.grep
  2. Place a .env file in your project directory containing sensitive values
  3. Ask OpenCode to search the repository for a specific string (e.g. a username)
  4. OpenCode delegates the search to a sub-agent via the task tool
  5. The sub-agent reads the .env file and returns the sensitive content to the parent agent, which then presents it to the user

Expected behavior: The deny rules should be inherited and enforced in all sub-agents spawned via the task tool.
Actual behavior: Sub-agents ignore deny rules and freely read/grep denied files.

Screenshot and/or share link

N/A

Operating System

macOS (darwin) 26.5.1

Terminal

zsh

Activity

  1. github-actions commented on Jun 12, 2026

    @github-actions
    Contributor

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

    If this is the same underlying problem, it may be worth consolidating with that issue.

  2. JustSidus commented on Jun 12, 2026

    @JustSidus

    This is the same root cause as #23519 but for read/grep instead of edit/write. PR #18761 by @OpeOginni appears to be working on standardizing permission path handling across all tools, which should fix both issues.

  3. github-actions commented on Aug 12, 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