This is an AI written issue based on a bug that I found while working on a project.
Before submitting
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
- Have a project with commands on disk, e.g.
<project>/.claude/commands/deploy.md and review.md. - Open that project in the desktop app (nightly), Claude provider.
- 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:123const{ cwd }=yield*ServerConfig;// :159probeClaudeCapabilities(effectiveConfig,processEnv,cwd)// :165checkClaudeProviderStatus(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
- Use the active project/worktree path for
probeClaudeCapabilities and discoverClaudeSkills instead of ServerConfig.cwd. - 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.
This is an AI written issue based on a bug that I found while working on a project.
Before submitting
Area
apps/server
Summary
Project-level slash commands in
<project>/.claude/commands/*.mdnever appear in the/composer autocomplete when running the desktop app. Only user-level~/.claude/commandsand 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/commandscounterpart of #2048 (skills). #2048 was closed by #2124, which threadedServerConfig.cwdinto the probe — that fixesnpx t3launched from inside a repo, butServerConfig.cwdis never the open project in the desktop app. #3040 is the Codex-side twin.Steps to reproduce
<project>/.claude/commands/deploy.mdandreview.md./in the composer.Expected behavior
/deployand/reviewappear in the autocomplete for that project.Actual behavior
Only
~/.claude/commandsentries and built-ins appear. Project commands are absent, for every project. Typing/deployand sending it works fine.Root cause
ClaudeDriver.tstakes the cwd for both the capability probe and skill discovery from the globalServerConfig, which is the server process's own working directory: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
Cacheis capacity 1 / 5 min TTL (ClaudeDriver.ts:155), and the snapshot is persisted to<baseDir>/caches/<instanceId>.jsonand rehydrated on start withslashCommandsincluded (providerStatusCache.ts:68,:91).discoverClaudeSkillsshares the same cwd (ClaudeSkills.ts:104scans<cwd>/.claude/skills), which is why #2048 still reproduces on this build.Thread sessions are unaffected —
ClaudeAdapter.ts:3523-3527passes 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 readinginitializationResult().commands:/Users/me(= what the desktop app passes)/Users/me/dev/MyProjectannouncement, build, deploy, linear, prod-investigate, push, reviewThe 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):The server sits in
$HOMEwhile its own session subprocesses sit in the project.Suggested fix
probeClaudeCapabilitiesanddiscoverClaudeSkillsinstead ofServerConfig.cwd.(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.