[Bug]: OpenCode cold-start snapshot still caches zero skills after #31074 #35283

Summary

The OpenCode provider caches an empty skill list on a cold start. The composer / menu then lists only compact, and the skills never come back on their own.

This is the shape #31074 fixed, and it still reproduces on the nightly that contains that fix. disable-model-invocation: true is not involved. OpenCode returns all 132 skills for the same directory.

Evidence

Before, T3's cached provider snapshot, written at 13:29:08Z, the second the OpenCode server restarted:

"checkedAt": "2026-11-12T13:29:08.885Z",
"skills": [],
"slashCommands": [{ "name": "compact" }]

After, the live OpenCode API on the same server, for the same directory:

GET /api/skill?location[directory]=~/.t3/worktrees/<repo>/<worktree-id>
200, 132 skills

A cold location reads empty until its scan finishes, which is reproducible against OpenCode alone:

t+0s  skill.list -> 200 {"data": []}
t+1s  skill.list -> 200 {"data": [133 skills]}

So the read that filled the snapshot landed inside the scan window.

Area

apps/server, OpenCode provider, cold workspace snapshot.

Steps to reproduce

1. Run OpenCode 2.2.7 as the provider, desktop build 0.1.10-nightly.20261112.4580.
2. Start T3 Code so it spawns its own opencode serve.
3. Open a project or worktree while that server is still scanning its first location.
4. Open / in the composer. Only compact is listed. Reopening the menu does not heal it.

Expected behavior

The menu lists the skills OpenCode reports for that directory.

Actual behavior

The snapshot caches zero skills and zero commands. Only compact shows, and the menu stays empty until something forces another skill.list for the directory.

Impact

Major degradation. The agent still sees the skills, but nothing can be invoked from the UI.

Version or commit

0.1.10-nightly.20261112.4580 (Linux desktop), OpenCode 2.2.7.

Environment

Arch Linux, native OpenCode adapter, worktree thread. Skills live in ~/.claude/skills and ~/.agents/skills (132 total). Both roots are on disk and readable.

Logs and source notes

Two things in the bundled server code look relevant.

loadOpenCodeSkills calls client.app.skills(), which resolves to GET /api/app/skills. That route does not exist in OpenCode 2.2.7 (404), and the call is wrapped in orElseSucceed(() => []), so this path can only ever produce an empty list.

const loadOpenCodeSkills = (client) =>
  runOpenCodeSdk("app.skills", (signal) => client.app.skills(void 0, { signal }))
    .pipe(map((result) => (result.data ?? []).map(/* ... */)));
const loadSkills = (client) => loadOpenCodeSkills(client).pipe(orElseSucceed(() => []));

The v2 path is the one that should work, and its wait condition misses this case. The first read is returned when the directory is loaded and it has any commands. With zero commands, it falls through to waiting on command.updated plus skill.updated. If both events already fired before the subscription, the latch never clears, the 10s timeout expires, and the re-read is cached as-is.

const wasLoaded = yield* loaded;
const first = yield* read;
if (wasLoaded && first.commands.length > 0) return first;
yield* scanned.pipe(timeoutOption("10 seconds"));
return yield* read;

client.debug.location.list() also reports the directory as loaded while its scan is still partial, so a loaded directory is not a usable readiness signal on its own.

Workaround

Delete the cached snapshot and restart the agent session after the OpenCode server has finished scanning.

rm ~/.t3/caches/opencode.json

Duplicate check

Searched open issues. Closest are #31042 (closed by #31074 on 2026-11-11) and #16912 (closed). This build is from 2026-11-12 and includes #31074's loadOpenCode2Workspace wait, so this is a fresh report against that fix rather than a duplicate of an open issue.