agents: V1 theme color names silently drop agent files in V2 #54057

Activity

1. github-actions

   assigned

   kitlangton

   on Oct 9, 2026
2. opencode-agent commented on Oct 9, 2026

   

   opencode-agentBot

   on Oct 9, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I reproduced this on 2.0.26, and it still happens on the latest v2 commit (eefe85d) run from source.

   I used a separate, empty config directory with global agents in ~/.config/opencode/agents/, then ran opencode debug agents (repeating it until the list settled):

   • color: accent, color: warning and color: success each make the agent disappear, with no warning.
   • color: "#9d7cd8" and no color both load.
   • color: warning with a v2 permissions array: the agent is dropped.
   • color: warning with a v1 permission block: the agent loads, but its color becomes #aaaaaa.

   From reading the code, it looks like files with only v2 fields are checked against a hex-only color rule, and a file that fails that check is skipped without a log message. Files with v1-only fields go through the legacy translation, which accepts the color name but replaces it with #aaaaaa.

   The script below reproduces it. Until this is fixed, your workaround of using a six-digit hex color keeps the agents loading.

   Reproduction script (repro.sh)

   #!/usr/bin/env bash
   # Repro for #54057: V1 theme color names silently drop agent files in V2.
   # Usage: OC="opencode" bash repro.sh   (or OC="bun ... packages/cli/src/index.ts")
   set -u
   OC=${OC:-opencode}
   ROOT=$(mktemp -d /tmp/opencode/oc54057.XXXX)
   export HOME=$ROOT/home XDG_CONFIG_HOME=$ROOT/home/.config XDG_DATA_HOME=$ROOT/home/.local/share XDG_STATE_HOME=$ROOT/home/.local/state XDG_CACHE_HOME=$ROOT/home/.cache
   A=$XDG_CONFIG_HOME/opencode/agents; mkdir -p $A $ROOT/proj
   mk(){ printf -- "---\ndescription: $1 agent\nmode: subagent\n$2\n---\nBody.\n" > $A/$1.md; }
   mk theme_accent  'color: accent'
   mk theme_warning 'color: warning'
   mk theme_success 'color: success'
   mk hex_color     'color: "#9d7cd8"'
   mk no_color      ''
   mk warn_v2perm   $'color: warning\npermissions:\n  - action: subagent\n    resource: "*"\n    effect: deny'
   mk warn_v1perm   $'color: warning\npermission:\n  task:\n    "*": deny'
   cd ${RUN_DIR:-$ROOT/proj}
   $OC --version
   $OC service stop >/dev/null 2>&1 || true
   # agent loading is async after startup: poll until the list settles
   for i in 1 2 3 4 5 6; do OUT=$($OC debug agents 2>&1); grep -q no_color <<<"$OUT" && break; sleep 2; done
   echo "$OUT" > $ROOT/out.txt; echo "full output: $ROOT/out.txt"
   for n in theme_accent theme_warning theme_success hex_color no_color warn_v2perm warn_v1perm; do
     if grep -q "$n" <<<"$OUT"; then echo "$n: LOADED"; else echo "$n: MISSING"; fi
   done
   echo "--- warn_v1perm color:"; grep -A12 "\"id\": \"warn_v1perm\"" <<<"$OUT" | grep color
   
   $OC service stop >/dev/null 2>&1 || true

   Run it: bash repro.sh
3. opencode-agent

   added

   reproduced

   on Oct 9, 2026
4. abinawahasan-bot commented on Oct 18, 2026

   

   abinawahasan-bot

   on Oct 18, 2026

   More actions

   Confirming on the current release: this still reproduces on 2.0.32.

   Real-world impact (a real global ~/.config/opencode/agents/ with 58 custom agent files): 13 of 58 were silently dropped — the ones whose frontmatter had only description / mode / color: <theme name> and no V1-only key. The dropped files included orchestrator (mode: all), architect, and the developer/engineer/reviewer agents. Because orchestrator was still selectable as the configured default_agent, it kept running with an empty system prompt (0 chars) — its ~18K prompt was silently lost, with no warning anywhere.

   Controlled matrix on 2.0.32

   Base frontmatter description + mode: subagent; only the last field(s) varied. Checked after a full server restart (opencode reload immediately after creating the files is racy — the list can read empty until the async scan settles):

   frontmatter additions	loaded
   color: accent	❌ dropped
   color: "#ff8800"	✅
   (no color)	✅
   color: accent + permission: {}	✅
   color: accent + temperature: 0.3	✅
   color: accent + top_p: 0.9	✅
   color: accent + hidden: false	❌ dropped

   Refinement to the two-parse-path diagnosis

   The rescue is not "any extra key" — it is specifically a V1-only field (permission, temperature, top_p) forcing the legacy path. hidden is accepted by both schemas, so hidden: false does not rescue the file. That matches: files that don't hit the legacy path are validated against the hex-only color rule and dropped without a log line.

   Minimal, behavior-preserving workaround

   Instead of converting theme names to hex (loses the theme color) or keeping a V1 permission block, an empty V1 block is enough:

   color: accent
   permission: {}

   permission: {} yields an identical effective permission ruleset to having no permission key at all, so it changes no behavior while keeping the theme color name.

   Just adding the release confirmation, the real-world scope, and the hidden data point on top of the root-cause analysis above.
5. rekram1-node

   closed this as completedin #57910on Oct 22, 2026