fix(server): discover Claude commands and skills per workspace - #7118
fix(server): discover Claude commands and skills per workspace#7118RaitP1 wants to merge 3 commits into
Conversation
- Add server.listProviderWorkspaceCapabilities RPC that resolves slash commands and skills for a project's or thread's actual cwd (worktree when present), instead of the process-wide provider snapshot - ClaudeDriver gains listWorkspaceCapabilities, caching per-cwd probes and skill discovery - Web and mobile composers query workspace capabilities for the "/" and "$" menus, falling back to the provider snapshot when unavailable - Document the workspace-scoped behavior in docs/user/providers-claude.md
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ApprovabilityVerdict: Needs human review This PR introduces new per-workspace discovery of Claude commands and skills, including a new RPC endpoint, client hooks, and caching logic. As a new feature that changes user-facing behavior (which commands/skills appear based on workspace), it warrants human review. You can customize Macroscope's approvability policy. Learn more. |
…empty list A projection read error was swallowed and answered as an empty result, which the client cached like real data, so one transient failure could blank the `/` and `$` menus. The read now fails with OrchestrationGetSnapshotError, and the composer keeps the snapshot list until it retries. When no workspace resolves, the registry answers from the provider snapshot rather than with an empty list, so an empty answer only ever means empty. Drop the five-minute client stale time. The server already caches per directory, so the default thirty seconds picks up a new worktree quickly and costs a cache hit.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 990e75a. Configure here.
…esolve A thread id that is absent from the projection, or that belongs to another project, forced the workspace to null and answered from the provider snapshot, so the menus showed server-cwd entries for a project that had already resolved. A new thread that has not projected yet hit this. Use the project folder in that case, which is what omitting the thread id already does. The snapshot now answers only when the project itself does not resolve.

What Changed
Why
Commands and skills that live inside a project never appear in the
/and$menus, and every project shows the same list. Typing the command still works, because the thread itself runs in the project folder. Only the menus are wrong.Discovery asks the directory the server process started in, not the project the user has open. In the desktop app those are never the same. The answer is then cached per provider, with nothing that records which project it came from, so opening another project cannot refresh it.
Left out on purpose: other providers keep their current behavior, and a probe that fails drops its cached entry instead of leaving a menu empty for the next five minutes.
Related: #4658. #4546 proposes the skills half of this, for the
$picker only.Checklist
Written by Claude Opus 5 in Claude Code, running inside T3 Code.
Note
Medium Risk
New read RPC and cwd resolution from projections affect composer discovery; Claude runs per-workspace probes with caching, but behavior falls back to snapshots for non-Claude providers and failed probes.
Overview
Workspace-scoped provider menus — Web and mobile composers no longer rely only on the global provider snapshot for
/slash commands and$skills. While those menus are open, they calluseProviderWorkspaceCapabilities, which hitsserver.listProviderWorkspaceCapabilitieswith project/thread ids (no client paths).Server resolution — The WS handler resolves cwd from the thread worktree when it belongs to the project, otherwise the project workspace root, then
ProviderRegistry.listWorkspaceCapabilities. Drivers may implementlistWorkspaceCapabilities(cwd); others keep snapshot lists.Claude —
ClaudeDriverprobes capabilities and discovers skills in that cwd, caches per workspace (~5 minutes), and falls back to snapshot slash commands if the probe is empty.Docs note that menus reflect the thread’s workspace folder.
Reviewed by Cursor Bugbot for commit 7c05f4e. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Discover Claude slash commands and skills per workspace in chat composers
server.listProviderWorkspaceCapabilitiesRPC that resolves the workspace directory from the active thread's worktree path or project root, then queries the Claude provider for workspace-scoped slash commands and skills.ClaudeDrivergains alistWorkspaceCapabilities(cwd)method backed by a capacity-8 cache, concurrently probing Claude capabilities and discovering skills, with fallback to the cached snapshot.useProviderWorkspaceCapabilitieshook when a slash-command or skill trigger is active, falling back to provider snapshot data if the query is unavailable.Macroscope summarized 7c05f4e.