Skill picker lists the server's startup-directory skills, not the active project's

[Brechard]

Note

🤖 Claude Opus 5 writing on behalf of Rodrigo

Summary

The composer's $ skill picker discovers skills from the server process's own startup directory rather than from the project the user has open. With more than one project configured, the picker shows another project's skills — or none at all.

Cause

discoverClaudeSkills scans <cwd>/.claude/skills for project-scope skills, and that cwd traces back to ServerConfig.cwd, which is resolved once at server startup from the cwd CLI argument or process.cwd() (apps/server/src/cli/config.ts). It is a single process-wide value, not per-project.

The path that actually matters — the thread's worktree, else the project's workspaceRoot — is used when running turns (resolveThreadWorkspaceCwd) but never for skill discovery. The Codex provider has the same shape: it requests skills/list with cwds: [process.cwd()].

Discovery is also silent about failures: an unreadable skills directory, an unreadable SKILL.md, and malformed YAML frontmatter are each swallowed with no log, so a misconfigured or wrongly-scoped path is indistinguishable from "this project has no skills".

Reproduction

1. Have a repo with skills in .claude/skills/<name>/SKILL.md.
2. Start the server from a different directory than that repo (the normal case for the desktop app).
3. Open that repo as a project, open a thread, type $ in the composer.

Expected: the project's skills appear alongside the user's global ~/.claude/skills, with the user copy winning a name collision.

Correction (2026-08-28): this line originally said project scope should win a collision, "matching Claude Code's most-specific-wins resolution". That was wrong. Measured against claude 2.1.250, the user copy wins, with a project-only control run proving the project copy loads on its own. Evidence is in this comment. Correcting it in place rather than only in a comment because an acceptance case is being assembled from this issue, and the original wording would reinstate the inverted precedence.

Actual: only the global user skills are listed. A project skill sharing a name with a user skill does not override it.

Note

ProviderRegistry depends only on ServerConfig and ProviderInstanceRegistry, so it cannot resolve which project a client is viewing. The clients already compute that path, which suggests the workspace should travel in the request rather than being inferred server-side.

[balazsegyed]

Still reproduces on today's nightly, 0.0.34-nightly.20260823.1164 on macOS.

Fresh provider cache (~/.t3/caches/claudeAgent.json) after the new build's probe: 23 skills, every one scope: "project", every path under ~/.claude/skills/. My actual project skill (<repo>/.claude/skills/deploy) is absent from the $ picker and from the / command list (103 commands, user scope only). So both symptoms folded in here from #4544 and #4658 are still present.

The impact is wider than the picker itself. Project skills are invisible in every packaged desktop install, and every user skill carries a wrong "Project" badge, so the scope labels can't be trusted at all.

It also looks like a small fix at this point: discoverClaudeSkills already takes a cwd parameter, and the clients already compute the active project root. Three PRs with the same basic approach of resolving against the workspace root are sitting unreviewed (#6450, #7882, #7909). I'm on the nightly channel and happy to verify whichever one you want to land.

[janb-sc]

Confirming this on the Claude provider (macOS), with a cache snapshot that also explains the "user skills show up as project skills" symptom some people are hitting.

Environment: T3 Code (Nightly), macOS (Darwin 25.6.0), claude-agent provider 2.1.241, Node 26.7.0.
Open project: /Users/jan/web — repo skills at /Users/jan/web/.claude/skills/: seo-publish, gsc-audit, verify.
User skills: ~/.claude/skills/: grill, unslop, writing-for-agents.

The $ picker shows only the three user skills and lists none of the three repo skills. ~/.t3/caches/claudeAgent.json skills array:

[
 {"name":"grill","scope":"project","path":"/Users/jan/.claude/skills/grill/SKILL.md"},
 {"name":"unslop","scope":"project","path":"/Users/jan/.claude/skills/unslop/SKILL.md"},
 {"name":"writing-for-agents","scope":"project","path":"/Users/jan/.claude/skills/writing-for-agents/SKILL.md"}
]

Two things stand out: every path is under ~/.claude/skills, and every entry is tagged scope: "project" (not user). No /Users/jan/web/.claude/skills/* path appears at all.

This is exactly what the two-root scan (discoverClaudeSkills, per #5622) produces when ServerConfig.cwd resolves to the home directory /Users/jan:

{ directory: path.join(configDirPath, "skills"), scope: "user" }, // /Users/jan/.claude/skills
{ directory: path.join(cwd, ".claude", "skills"), scope: "project" }, // /Users/jan/.claude/skills <-- same dir when cwd == home

With cwd == /Users/jan, the "project" root collapses onto the "user" root. The project scan just re-reads the user skills and stamps them scope: "project", while the actually-open project at /Users/jan/web is never visited. So the same misresolved cwd causes both visible symptoms at once:

1. the open project's repo-local skills are missing from $, and
2. the user's own global skills are mislabeled project scope.

/reload-skills returns 29 skills available (no changes) and does not rescan the open project; fully restarting the app and deleting ~/.t3/caches/claudeAgent.json do not help either — consistent with the wrong cwd being re-resolved the same way each time. The skills stay invocable by name (the SDK session has them loaded), so this is discovery/labeling only, matching your writeup.

[archiekd]

@t3dotgg @juliusmarminge It would be great to get this sorted. I have multiple projects with different sets of skills so my skills aren't all top user level. At the moment I have having to type them fully out manually and it is easy to make a mistake when remembering the skill name.