[Bug]: Claude provider skill discovery missing cwd — project-level .claude/skills/ not discovered in composer autocomplete

[r3xsean]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

Project-level skills from .claude/skills/ are not discovered in the composer autocomplete when using the Claude provider. User-level skills from ~/.claude/skills/ appear correctly. Skills execute fine when typed manually — only the autocomplete/discovery is broken.

Tested on 0.0.17-nightly.20260415.45, Windows 11, Claude provider, 40+ project-level skills in .claude/skills/.

Root Cause

Two related discovery/UI issues after #1905:

1. Claude capability discovery doesn't pass cwd to the SDK

probeClaudeCapabilities enables settingSources: ["user", "project", "local"] but does not pass cwd, so the SDK resolves project/local sources relative to the T3 server process cwd instead of the active thread/project workspace cwd. This misses repo-local .claude/skills/ when those differ.

// ClaudeProvider.ts — probeClaudeCapabilities
const q = claudeQuery({
 prompt: ".",
 options: {
 settingSources: ["user", "project", "local"],
 // no cwd — SDK defaults to process.cwd() per SDK docs
 },
});

The probe cache is also cwd-unaware — keyed by binaryPath only with capacity 1:

const subscriptionProbeCache = yield* Cache.make({
 capacity: 1,
 timeToLive: Duration.minutes(5),
 lookup: (binaryPath: string) => probeClaudeCapabilities(binaryPath),
});

Compare with the Codex provider, which passes cwd explicitly and includes it in the cache key (capacity 4):

// CodexProvider.ts
const probeCodexCapabilities = (input: {
 readonly binaryPath: string;
 readonly homePath?: string;
 readonly cwd: string; // cwd required
}) => probeCodexDiscovery({ ...input, signal })

// Cache keyed by [binaryPath, homePath, cwd]
Cache.get(accountProbeCache, JSON.stringify([input.binaryPath, input.homePath, input.cwd]))

2. Claude discovery results only exposed as slashCommands

Claude discovery results are exposed only as slashCommands on the provider snapshot. That is sufficient for T3's / autocomplete picker, but not for the $ skill picker, because the Claude SDK's initialization command shape ({ name, description, argumentHint }) does not include the richer ServerProviderSkill fields T3 requires (path, enabled, scope, displayName, shortDescription).

// probeClaudeCapabilities returns:
return {
 subscriptionType: init.account?.subscriptionType,
 slashCommands: parseClaudeInitializationCommands(init.commands),
 // skills is never populated — always defaults to []
};

The composer routes these separately (ChatComposer.tsx):

• / trigger → reads provider.slashCommands
• $ trigger → reads provider.skills (always empty for Claude)

Impact

• Project-level skills (.claude/skills/) → not discovered, don't appear in any autocomplete
• User-level skills (~/.claude/skills/) → discovered correctly (no cwd needed), appear under /
• $ skill picker → empty for Claude regardless of scope (schema limitation)
• Manual invocation → works fine for both scopes (thanks to fix(claude): load Claude SDK filesystem setting sources #1334's settingSources fix)

Suggested Fix

1. Add cwd parameter to probeClaudeCapabilities and pass it through to the SDK's options.cwd — using the active project/workspace cwd, not just process.cwd() again
2. Include cwd in the probe cache key and increase capacity (like Codex's capacity-4 approach)
3. Longer term: consider whether Claude discovery results can also populate skills to enable the $ picker, acknowledging the schema gap

Related

• fix(claude): load Claude SDK filesystem setting sources #1334 — settingSources fix (merged, working — skills execute fine at runtime)
• Add provider skill discovery #1905 — provider skill discovery (merged, partially working — Codex path works, Claude path missing cwd)
• [Bug]: Claude provider slash commands not discovered; unrecognized command freezes UI #1329 — original slash command discovery bug (still open)
• Claude integration does not load installed Skills, Slash Commands, or CLAUDE.md memory #1283 — root cause settingSources issue (closed by fix(claude): load Claude SDK filesystem setting sources #1334)
• [Feature]: Auto-discover Claude skills #1480 — auto-discover Claude skills feature request (closed by Add provider skill discovery #1905)
• Claude should work when repo-local .claude settings make it available #1964 — repo-local .claude settings (open, related but focused on auth)

Environment

• T3 Code version: 0.0.17-nightly.20260415.45
• Platform: Windows 11
• Provider: Claude
• 40+ project-level skills in .claude/skills/, all with valid SKILL.md frontmatter
• Symptom: user-level skills appear in / autocomplete, project-level skills do not

[juliusmarminge]

$ is not a thing for Claude. They only have slash commands. Nothing we can do bout that

[r3xsean]

$ is not a thing for Claude. They only have slash commands. Nothing we can do bout that

oops, sorry, my bad! i thought it was something that t3 code did in general for all skills, didnt know that codex used it. the problem about autocomplete not catching project level skills remain though.

[archiekd]

$ is not a thing for Claude. They only have slash commands. Nothing we can do bout that

My project level skills are not showing up in my t3 code when on a project. This is currently stopping me using it completely.

[adamatti]

My project level skills are not showing up in my t3 code when on a project. This is currently stopping me using it completely.

+1

[eowca]

Confirming this still reproduces on Linux (report above is Windows 11) with T3 Code 0.0.28 (AppImage), Claude provider — so it persists well past 0.0.17-nightly.

Both symptoms from the root-cause analysis hold exactly:

• Project-level .claude/skills/ (36 skills, valid SKILL.md) — absent from the / composer autocomplete.
• $ picker shows only bundled/system skills regardless of scope — consistent with Claude discovery populating slashCommands but never skills.

Extra data points from debugging on this end:

• The skills are loaded for the agent — typing the full name (e.g. /code-review) executes the project skill fine; only discovery/autocomplete is broken (matches "manual invocation works").
• Materializing the skills as real directories in ~/.claude/skills/ (not symlinks) did not surface them in the $ picker — consistent with symptom Add open-in-editor feature with Cmd+O shortcut #2 (the $/Claude path is a schema gap, not a filesystem/symlink issue), so the fix really is on the discovery/schema side, not user config.
• No strictKnownMarketplaces / marketplace allowlist is set here, so the plugin-policy gate is not involved.

The suggested fix (pass workspace cwd into probeClaudeCapabilities + cwd-keyed cache, and populate skills for the $ picker) matches what we observe. +1 to prioritizing — this makes every repo-defined skill undiscoverable in the UI on the Claude provider.