Skip to content

Bug: Los subagentes heredan permisos deny del agente primario via deriveSubagentSessionPermission(), sobrescribiendo sus propios allow (regresion desde v1.14.46) #28052

Closed

Description

@ROKO108

Descripcion

Cuando se usa la herramienta task para delegar trabajo a un subagente, el subagente hereda TODAS las reglas deny del agente primario a traves de deriveSubagentSessionPermission(). Debido a la evaluacion "ultima coincidencia gana" (last-match-wins), estas reglas deny heredadas sobrescriben los permisos allow explicitos que el subagente tiene definidos en su frontmatter YAML.

Esto rompe efectivamente el patron commander+worker: un agente primario con permisos restringidos (ej: edit: deny) no puede delegar tareas de escritura a un subagente que tiene edit: allow en su propia configuracion.

Pasos para reproducir

  1. Configurar un agente primario con edit: deny en opencode.jsonc:
{
  "permission": {
    "edit": "deny"
  }
}
  1. Crear un subagente con edit: allow en su frontmatter:
---
name: mi-escritor
mode: subagent
permission:
  edit: allow
---
  1. Desde el agente primario, delegar una tarea al subagente via task

  2. El subagente NO tendra la herramienta write disponible, a pesar de tener edit: allow en su propio frontmatter.

Comportamiento esperado

Los permisos explicitos de un subagente deberian tener prioridad sobre los permisos heredados del agente primario. Si un subagente tiene edit: allow en su frontmatter, deberia tener acceso a las herramientas write, edit y apply_patch independientemente de los permisos del agente primario.

Comportamiento actual

El subagente hereda las reglas deny del agente primario. Debido a la evaluacion last-match-wins, el deny heredado sobrescribe el allow del subagente. La herramienta write (y otras herramientas de edicion) no estan disponibles para el subagente.

Analisis tecnico

El bug esta en deriveSubagentSessionPermission() en packages/opencode/src/agent/subagent-permissions.ts, que:

  1. Filtra las reglas deny del agente padre con parentAgent.permission.filter(rule => rule.action === "deny" && rule.permission === "edit")
  2. Las anade al conjunto de permisos de la sesion del subagente
  3. El runtime evalua Permission.merge(subagent.permission, session.permission) en packages/opencode/src/permission/index.ts (linea 267)
  4. Como Permission.merge() hace rulesets.flat(), y las reglas deny heredadas aparecen DESPUES de las reglas allow del subagente en el array, la evaluacion last-match-wins hace que ganen los deny

Issues relacionados

La regresion original se introdujo en v1.14.46 por el PR #26597 (fix para #26514: "Subagents Bypass Plan Mode READ-ONLY Restrictions"). El issue #26700 se suponia que arreglaria esto pero el fix parece incompleto — sigue heredando los deny del padre.

Workaround

Actualmente, el unico workaround es NO usar deny en el agente primario para los permisos que los subagentes necesitan. Usar ask en lugar de deny permite que los subagentes hereden ask que su propio allow puede sobrescribir. Sin embargo, esto no es ideal para configuraciones orientadas a seguridad donde el agente primario no deberia tener capacidades de edicion.

Entorno

  • Version de OpenCode: 1.15.3
  • SO: Windows (nativo, no WSL)
  • Patron de agentes: Coordinador primario con edit: deny + subagentes con edit: allow

Activity

  1. github-actions commented on May 17, 2026

    @github-actions
    Contributor

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

    • Redefining permission in subagents stopped working #27497: "Redefining permission in subagents stopped working" — describes the exact same problem: an orchestrator/primary agent with edit: deny causes subagents with edit: allow in their frontmatter to lose edit access, affecting v1.14.46+.

    If your issue adds new details or context beyond #27497, please note that in a comment there. Otherwise, consider closing this one to consolidate the discussion.

  2. ROKO108 commented on May 29, 2026

    @ROKO108
    Author

    ¿Cuándo se va a solucionar esto?

  3. ROKO108 commented on Jul 14, 2026

    @ROKO108
    Author

    @jlongster ¿Se sabe algo de esto? ¿Se va a solucionar en alguna actualización futura?

  4. ROKO108 commented on Aug 18, 2026

    @ROKO108
    Author

    Solucionado al separar los permisos del agente padre de los permisos de la sesión padre.

    TaskTool obtiene los permisos de la sesión hija a partir de parent.permission, que representa los permisos de la sesión padre, en lugar de heredar directamente los permisos configurados en el agente padre. Posteriormente, el subagente se evalúa utilizando sus propios agent.permission junto con los permisos derivados de su sesión.

    Como resultado, un deny configurado en el agente padre ya no se propaga a la sesión hija y, por tanto, ya no puede sobrescribir un permiso explícitamente permitido en el subagente delegado.

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