Skip to content

permission.skill / tools.skill in standalone agent .md frontmatter is parsed but silently ignored at config resolution #41712

Closed as not planned

Description

@Shagwu

Title: permission.skill / tools.skill in standalone agent .md frontmatter is parsed but silently ignored at config resolution

Summary

Setting permission.skill or tools.skill in a standalone agent definition
file (e.g. ~/.config/opencode/agents/<name>.md) is accepted without error —
the value appears verbatim in the raw prompt field returned by
opencode debug agent <name> — but does NOT propagate to the resolved
tools/permission object used at request time. The only way to actually
restrict skill access for an agent is to define the override inside
opencode.json's top-level agent.<name>.permission.skill block instead.

This is confusing because both locations use identical YAML/JSON syntax and
neither documentation nor CLI output indicates that one is authoritative and
the other is not.

Steps to reproduce

  1. Create ~/.config/opencode/agents/my-agent.md with frontmatter:
***
description: test agent
mode: primary
model: <any provider/model>
permission:
  edit: deny
  bash: ask
  skill:
    "*": deny
***
  1. Run opencode debug agent my-agent
  2. Observe: the prompt field shows the frontmatter exactly as written
    (including the skill: "*": deny block), but the resolved tools object
    at the bottom of the same output still shows "skill": true
  3. Confirm the tool is still callable: run opencode run "<any prompt that might invoke a skill>" --agent my-agent — the model can still invoke the
    skill tool and load skill content

Expected behavior

Either:
(a) permission.skill / tools.skill in standalone agent .md frontmatter
should be honored at resolution time, matching the behavior documented
for opencode.json's agent.* block, OR
(b) if standalone agent files intentionally support a reduced frontmatter
schema that excludes tool/permission overrides, this should be stated
explicitly in the docs and ideally surfaced as a warning/error when an
unsupported key is present, rather than silently accepted and ignored

Actual behavior

Silent no-op. The only working fix is duplicating the agent's tool
restriction inside opencode.json:

{
  "agent": {
    "my-agent": {
      "permission": {
        "skill": { "*": "deny" }
      }
    }
  }
}

Impact

For agents with a large local + global skill catalog (105 skills in one tested
case, ~1.29MB of serialized skill metadata), this caused every request to
carry an unnecessarily large tool-calling prompt, costing significant prompt
evaluation time and obscuring the real working configuration path.

Environment

  • OpenCode version: 1.18.15
  • OS: macOS (Apple Silicon)
  • Model provider: Ollama (local), qwen2.5-coder:14b-16k

Activity

  1. github-actions commented on Aug 11, 2026

    @github-actions
    Contributor

    This issue might be related to existing issues. Please check:

    These are not exact duplicates of your specific bug (permission.skill silently ignored at resolution time), but they share related context that may be useful.

  2. thdxr commented on Oct 11, 2026

    @thdxr
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

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