`.claude/agents` reuse is blocked: one unsupported `color` value fails the whole config decode

opencode already discovers skills from Claude Code's directories (.claude/skills, ~/.claude/skills), so a user with an existing Claude Code setup expects the neighbouring .claude/agents definitions to be reusable too. They are not, and the failure mode is harsher than a skipped file: a single unsupported color value in one agent markdown file rejects the entire configuration and opencode refuses to start.

Claude Code's agent frontmatter accepts exactly these eight colour names and no hex values: red, blue, green, yellow, purple, orange, pink, cyan. opencode accepts a #RRGGBB hex string or one of primary, secondary, accent, success, warning, error, info. The two sets are disjoint, so there is no value a user can write that satisfies both tools. Every real Claude Code agent file that sets a colour is therefore rejected.

I tested every other frontmatter field opencode does not know about, and they are all handled gracefully — name, model: sonnet, disallowedTools and arbitrary unknown keys are simply ignored. color is the outlier, together with a string-valued tools field.

Steps to reproduce

mkdir -p /tmp/oc-color/.opencode/agent
printf -- '---\ndescription: repro\ncolor: blue\n---\nbody\n' > /tmp/oc-color/.opencode/agent/t.md
cd /tmp/oc-color && opencode debug config

Observed:

Error: Configuration is invalid at /tmp/oc-color/.opencode/agent/t.md
↳ Expected a string matching the RegExp ...

opencode does not start. The same happens for cyan, green and the rest of the Claude Code palette.

Replacing blue with primary or #3b82f6 makes it start normally, which confirms the colour value is the only cause.

opencode version

1.18.25 (Homebrew, macOS 15.6)

Where it comes from

The colour union is declared identically in three places:

• packages/schema/src/agent.ts:13
• packages/core/src/config/agent.ts:8
• packages/core/src/v1/config/agent.ts:7

What I would like to confirm before writing a patch

CONTRIBUTING says core product changes need a design review first, so I would rather agree on the direction than send an unwanted patch. Two options look reasonable to me, and I am happy to implement either:

1. Accept the eight Claude Code colour names and map them onto existing theme tokens. Smallest change, keeps the rendered palette under opencode's theme control, and matches the compatibility that already exists for skills. It does add names to a union that is currently deliberately semantic.

2. Do not widen the union, but stop letting one bad agent file take down the whole config. Skip the offending agent (or drop just the invalid field) and surface a warning. This is arguably the more valuable fix regardless of the colour question, because today any malformed agent file is fatal rather than skipped.

My own preference is 2, with 1 as a follow-up if you want the compatibility, since 2 also covers the string-valued tools case and every future field mismatch. But I will follow whichever direction you prefer.

Related: #38796 reports that the documented named tokens are rejected on the v2 branch; on 1.18.25 the named tokens work and only non-opencode names fail, so that issue looks separate from this one.