[Bug]: Pi provider lacks per-workspace skill discovery — project .agents skills never appear in the $ picker #15810

Activity

1. v-senninha-v

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026
2. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @v-senninha-v for the detailed root-cause write-up and the workaround. It checked out against current main (efecd3cf8b).

   What I found

   • ProviderRegistry.refreshWorkspaceSnapshot (apps/server/src/provider/Layers/ProviderRegistry.ts) returns the current provider list without scanning when the instance has no snapshotForCwd. PiDriver is the only driver that leaves it out. Claude, Codex, Cursor, Grok, OpenCode, and Antigravity all implement it. The field is optional in ProviderDriver.ts, so this type-checks.
   • The machine-level catalog comes from checkPiProviderStatus, which uses the server process cwd (ServerConfig.cwd). discoverPiViaRpc passes that cwd into pi --mode rpc, so get_commands only sees skills that are visible from there. Where that cwd ends up depends on how T3 is run:
     • Packaged desktop app: the home directory (backendCwd in DesktopEnvironment.ts).
     • Unpackaged desktop build: the app root.
     • npx t3: whatever directory the server was started in.
   • The composer already asks for a workspace scan and prefers workspaceSnapshots for the thread cwd (resolveProviderSkillsForCwd in packages/client-runtime/src/providerSkills.ts). When there's no snapshot, it falls back to provider.skills, and each re-ask does nothing on the server.
   • The live Pi session works because the adapter starts pi in the thread cwd. That's why the model can list the project skill, and why typing /skill:<name> still runs it.
   • Project slash commands are hidden the same way, because / uses resolveProviderSlashCommandsForCwd with the same fallback.
   • These are related but aren't duplicates:
     • [Bug]: Project skills that a new worktree receives after creation never appear in the $ picker #14801 is Claude, when a worktree gains skills after the first scan.
     • [Bug]: Workspace snapshot taken before the first Claude probe finishes leaves the / menu without provider commands for the whole session #11575 is Claude storing the pending launch probe as the workspace command list.

   Likely fix area

   One option is to add snapshotForCwd to PiDriver. It would run the existing short-lived get_commands discovery in the requested cwd, using that instance's launch args, and lay both skills and slashCommands over the machine snapshot. Some details to keep in mind:

   • The cwd result has to be the full set Pi exposes there, user skills included, because the client replaces the machine list with it.
   • Keeping the existing discovery timeout means an untrusted project can't hang on Pi's trust prompt.
   • A regression test could show that a Pi cwd probe lands in workspaceSnapshots while the machine-level skills stay unchanged.

   Until then, the workaround in the report works: point Pi's user skills setting at the project's .agents/skills, or type /skill:<name>.

   A maintainer will decide on the fix direction.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026
4. Yash-Singh1

   closed this as completedin #17190on Oct 8, 2026