[Bug]: Project-level .claude/commands not discovered in desktop app — capability probe uses server cwd, not the project

[rithwikshetty]

This is an AI written issue based on a bug that I found while working on a project.

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 slash commands in <project>/.claude/commands/*.md never appear in the / composer autocomplete when running the desktop app. Only user-level ~/.claude/commands and built-ins show, and the same list is shown for every project in the sidebar.

The commands themselves execute correctly if you type them blind, because thread sessions run in the project directory. Only discovery is broken.

This is the .claude/commands counterpart of #2048 (skills). #2048 was closed by #2124, which threaded ServerConfig.cwd into the probe — that fixes npx t3 launched from inside a repo, but ServerConfig.cwd is never the open project in the desktop app. #3040 is the Codex-side twin.

Steps to reproduce

1. Have a project with commands on disk, e.g. <project>/.claude/commands/deploy.md and review.md.
2. Open that project in the desktop app (nightly), Claude provider.
3. Type / in the composer.

Expected behavior

/deploy and /review appear in the autocomplete for that project.

Actual behavior

Only ~/.claude/commands entries and built-ins appear. Project commands are absent, for every project. Typing /deploy and sending it works fine.

Root cause

ClaudeDriver.ts takes the cwd for both the capability probe and skill discovery from the global ServerConfig, which is the server process's own working directory:

// apps/server/src/provider/Drivers/ClaudeDriver.ts:123
const { cwd } = yield* ServerConfig;
// :159
probeClaudeCapabilities(effectiveConfig, processEnv, cwd)
// :165
checkClaudeProviderStatus(
  effectiveConfig,
  () => Cache.get(capabilitiesProbeCache, capabilitiesCacheKey),
  processEnv,
  cwd,
)

In the desktop app that cwd is the user's home directory, not the open project. The probe options are otherwise correct — settingSources: ["user", "project", "local"] (ClaudeProvider.ts:569) — so the SDK would find the commands if it were given the right directory.

Discovery is also cached per provider instance with no project dimension, so switching projects cannot help even in principle: the in-memory Cache is capacity 1 / 5 min TTL (ClaudeDriver.ts:155), and the snapshot is persisted to <baseDir>/caches/<instanceId>.json and rehydrated on start with slashCommands included (providerStatusCache.ts:68, :91).

discoverClaudeSkills shares the same cwd (ClaudeSkills.ts:104 scans <cwd>/.claude/skills), which is why #2048 still reproduces on this build.

Thread sessions are unaffected — ClaudeAdapter.ts:3523-3527 passes the thread's own cwd plus the same setting sources, which is why manual invocation works.

Evidence

Running T3's own probe options (buildClaudeCapabilitiesProbeQueryOptions, verbatim: persistSession: false, settingSources: ["user","project","local"], allowedTools: [], mcpServers: {}, strictMcpConfig: true, never-yielding prompt) against two directories and reading initializationResult().commands:

probe cwd	project commands returned
/Users/me (= what the desktop app passes)	none
/Users/me/dev/MyProject	announcement, build, deploy, linear, prod-investigate, push, review

The SDK finds them. It is just never asked in the right place.

And the actual working directories of the running nightly (lsof -a -p <pid> -d cwd):

pid 51255  T3 server (app.asar/apps/server/dist/bin.mjs)   cwd = /Users/me
pid 52756  claude session, MyProject thread                cwd = /Users/me/dev/MyProject
pid 75896  claude session, MyProject thread                cwd = /Users/me/dev/MyProject

The server sits in $HOME while its own session subprocesses sit in the project.

Suggested fix

1. Use the active project/worktree path for probeClaudeCapabilities and discoverClaudeSkills instead of ServerConfig.cwd.
2. Key both the in-memory probe cache and the on-disk snapshot by (instanceId, projectPath) rather than instance alone, and raise capacity above 1.

Happy to test a nightly, and happy to put up a small PR if that is wanted.

Impact

Major degradation or frequent failure

Version or commit

0.0.29-nightly.20260727.920 (5719e8a)

Environment

macOS 26.5.2 (25F84), desktop app (nightly), Claude provider, Claude Code CLI 2.1.220

Workaround

Type the command without autocomplete — it resolves and runs correctly. Alternatively launch the server from the project directory (t3 --cwd <project>), which does not generalise to multiple projects in the desktop app.

Related

#2048 (skills, closed by #2124 — same root cause, still reproduces), #3040 (Codex twin), #1329, #1283.