Skip to content

v2: subagent model overrides are accepted without user authorization #51071

Description

@WillisLogan

Description

The V2 subagent tool exposes an optional model argument to the parent model. The tool description tells the parent model not to set this field unless the user explicitly requests a particular model, but that instruction is advisory prompt text rather than an enforced runtime constraint.

In OpenCode v2.0.15, a parent-supplied model is resolved and used with the following precedence:

const model = override ?? agent.model ?? parent.model

The subagent permission check only includes the agent ID:

permission.assert({
  action: name,
  resources: [agent.id],
  // ...
})

The model provider, model ID, and variant are not included in the permission resource or otherwise checked against user authorization.

As a result, a primary agent can silently route a child session to another provider/model/variant based on its own judgment. The user does not have to configure that model or explicitly approve the change. This can unexpectedly change cost, provider, and data-routing behavior.

This is not a request to remove dynamic model selection. It is a request to enforce the boundary between model selection and user authorization: an override should either be rejected unless explicitly user-authorized, or be included in the subagent permission prompt/allowlist.

Plugins

superpowers@git+https://github.com/obra/superpowers.git

OpenCode version

2.0.15

Steps to reproduce

  1. Run OpenCode v2.0.15.
  2. Do not configure agents.general.model; verify that the built-in general agent has no configured model.
  3. Start a primary session using opencode-go/space-bunny-free.
  4. Ask the primary agent to delegate an ordinary task to the general subagent without naming or requesting any model.
  5. Inspect the parent session's subagent tool call and the child session metadata.
  6. In the observed run, the parent supplied model values such as:
    • opencode-go/deepseek-v4-pro
    • opencode-go/deepseek-v4.1-flash
  7. The child sessions then ran using those same models, even though the user prompt did not request a model and general had no configured model.
  8. Observe that the subagent permission request identifies the agent, but does not identify or authorize the selected model.

The exact parent prompt can affect whether the parent chooses to emit the optional field; the defect is that OpenCode accepts the field without enforcing the stated authorization rule.

Screenshot and/or share link

No screenshot. The issue can be reproduced by inspecting the parent subagent tool input and the child session model through the session API.

Operating System

macOS (Darwin 25.6.0, arm64)

Terminal

VS Code integrated terminal (TERM_PROGRAM=vscode, TERM=xterm-256color)

Additional context

Relevant v2.0.15 implementation:

  • packages/core/src/tool/plugin/subagent.ts
    • Input.model says “NEVER set this unless the user explicitly asks...” (lines 36–38)
    • permission assertion covers only agent.id (lines 138–151)
    • input.model is resolved as an override (line 168)
    • the child model is selected as override ?? agent.model ?? parent.model (line 184)

Source:
https://github.com/anomalyco/opencode/blob/6f3639d82ed0760091792189b78f8eeb44f699b1/packages/core/src/tool/plugin/subagent.ts

Related existing discussion:
#6651

Activity

PVLPM commented on Oct 4, 2026

@PVLPM

Similar issue with OmO-Slim and Superpowers. Orchestrator almost always ignores the active subagent LLM presets.

yantushui commented on Oct 4, 2026

@yantushui

I think it's opencode's fault, I never allow the subagent to choose the ai itself.

Dante-dan commented on Oct 5, 2026

@Dante-dan

The current v2 code path confirms that an explicit model override bypasses the configured/inherited model after an agent-only permission check. The prompt warning does not enforce user authorization. #6651 established dynamic selection, but does not settle this authorization boundary.

I propose keeping dynamic selection and adding a separate subagent_model permission for explicit overrides, with the canonical provider/model#variant as the resource. Resolve and validate the model first, then check that permission before creating a child or switching an existing child. Approval of subagent: general would authorize delegation, not the model override; no-override calls would keep their current configured/inherited model behavior. Existing explicit wildcard permissions would retain their normal meaning.

Verification would cover create and resume paths, agent-only approvals, model allow/ask/deny rules, variants, and denial leaving child state unchanged. This is a new core authorization policy, so I am requesting design review before implementation: is a separate permission the intended approach, or should the model be part of the existing subagent permission resource?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    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