Windows: GET /api/skill returns an empty array with skill roots configured (2.0.32) #57524

Activity

1. opencode-agent commented on Oct 20, 2026

   

   opencode-agentBot

   on Oct 20, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I could reproduce the empty list, and it isn't specific to Windows: on Linux, with one configured skill root, opencode api --standalone GET /api/skill returns {"data":[]} every time on 2.0.32 and also on 2.1.1. Even the built-in opencode skill is missing, which matches what you saw with "skills": [].

   It looks like a startup timing issue. The skill list is read before the plugins that register skills have finished loading. With the background service, the first request for a project directory also returns [], and the same request a few seconds later lists all the skills, including the ones from the configured root. --standalone always starts a fresh server, so it always hits this. The handler for this endpoint is unchanged on the latest dev (3fdb13b). This is the same problem that the closed, unmerged PR #51687 tried to address.

   The script below reproduces it.

   I couldn't check your other point, that agent turns on Windows get no skills at all. Agent sessions wait for plugins to finish loading before reading skills, so that part may be a separate Windows problem. A maintainer with a Windows machine will need to look at it.

   Related: #51687 (same startup timing issue), #57035 (empty skill list, symlinked skills on Linux), #50147 (project skills missing from a session because of load order).

   Reproduction script (repro.sh)

   #!/usr/bin/env bash
   # Reproduces: `opencode api --standalone GET /api/skill` returns {"data":[]} even with skill roots configured.
   # Usage: OPENCODE="opencode" bash repro.sh   (or OPENCODE="bun ... packages/cli/src/index.ts")
   set -u
   OPENCODE=${OPENCODE:-opencode}
   ROOT=$(mktemp -d)
   mkdir -p "$ROOT/skills/demo" "$ROOT/project" "$HOME/.config/opencode"
   printf -- '---\nname: demo\ndescription: demo skill\n---\nbody\n' > "$ROOT/skills/demo/SKILL.md"
   echo "{\"skills\":[\"$ROOT/skills\"]}" > "$HOME/.config/opencode/opencode.jsonc"
   cd "$ROOT/project"
   $OPENCODE --version
   echo "--- standalone (cold private server):"
   for i in 1 2 3; do timeout 90 $OPENCODE api --standalone GET /api/skill 2>/dev/null | grep -o '"id":"[^"]*"\|"data":\[\]' | tr '\n' ' '; echo; done
   echo "--- background service, same location, repeated:"
   for i in 1 2 3; do timeout 90 $OPENCODE api GET /api/skill --param "location[directory]=$ROOT/project" 2>/dev/null | grep -o '"id":"[^"]*"\|"data":\[\]' | tr '\n' ' '; echo; sleep 3; done

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

   added

   reproduced

   on Oct 20, 2026
3. pablomadriaga commented on Oct 21, 2026

   

   pablomadriaga

   on Oct 21, 2026

   More actions

   Additional Windows reproduction with the npm-installed OpenCode CLI v2.1.1 (headless API; no model prompt):

   • A cold opencode api --standalone GET /api/skill returned {"data":[]} despite an installed, valid skill. --print-logs --log-level all showed no skill-loading error.
   • For a new project location on the shared service, the first /api/skill and /api/plugin reads returned empty lists. Later reads for the same location returned skills (we observed 2, then 10, including our required skill) and 89 plugins. The skill file did not change.
   • This affects automation: our preflight queried the catalogue for a fresh worktree, interpreted the initial empty skill list as skill_missing, and stopped before creating an ACP session or sending a prompt. Preflight on a previously warmed location had succeeded, so its ready result did not predict the fresh location's catalogue response.

   This corroborates the startup/readiness race identified above, not a permanently missing skill or a Windows-only loading failure. We have not established that the skill is absent from an actual agent session; the observed failure is specifically the early API catalogue response. Ideally /api/skill would wait for plugin activation (as proposed in #51687) or expose readiness so clients can distinguish not initialized from a genuinely empty catalogue.
4. usakim97

   closed this as completedon Oct 21, 2026
5. pablomadriaga commented on Oct 21, 2026

   

   pablomadriaga

   on Oct 21, 2026

   More actions

   Thanks for the report. Could we keep this open until a fix or verified release is identified? Our independent Windows reproduction on the npm CLI v2.1.1 (above) found that a cold private /api/skill request returned [], while later reads for the same project location returned the installed skills. The proposed readiness fix in #51687 was closed without merging, and I don't see a merged fix linked here. We added bounded retries against the same private server as a client-side workaround; the early API response remains ambiguous. If this was fixed in another commit or in v2.1.2, please point us to it and I'll retest. Otherwise, could this issue be reopened? This evidence concerns the API catalogue; it does not establish that skills are absent from actual agent sessions.
6. usakim97

   reopened this on Oct 22, 2026