[Bug]: ACP Registry providers probe commands/skills with the server cwd, so project-scoped commands never appear #24378

Area

apps/server (provider layer) / packages/provider-acp-registry

Summary

ACP Registry providers are probed for available_commands with cwd: host.paths.cwd — the server process working directory — instead of the project being viewed. Commands that a CLI scopes to the project therefore never reach the composer, for that project. Only commands from the agent's global config are listed.

Because ACP skills are derived from command names that start with $ (normalizeAcpRegistryCommands), project-scoped skill-like entries are invisible for the same reason.

Steps to reproduce

1. Enable an ACP Registry agent whose CLI supports project commands (e.g. opencode-v2, distribution: auto).
2. In a project, create:
   • <project>/.opencode/command/demo.md
   • <project>/.opencode/command/$demo-skill.md
3. Open a thread on that ACP provider in that project.
4. Press / and $.

Expected behavior

demo appears in the / list and demo-skill appears in the $ list, matching what the agent advertises for that working directory.

Actual behavior

Neither appears. Only globally scoped commands are listed (built-ins plus anything under the agent's global config dir). A global $<name>.md command does appear as a skill, which confirms the $ mapping itself works.

Evidence

Talking to the same agent binary directly over ACP with the project cwd advertises the project commands:

{"sessionUpdate":"available_commands_update","availableCommands":[
  {"name":"init","description":"guided AGENTS.md setup"},
  {"name":"review","description":"review changes [commit|branch|pr], defaults to uncommitted"},
  {"name":"$demo-skill"},
  {"name":"demo"},
  {"name":"compact","description":"Compact the session"}]}

The first advertisement arrives immediately after session/new, so this is not a timing/grace-window issue. Running the same handshake with the server's cwd returns the built-ins only.

Root cause

• checkAcpRegistryProviderStatus({ ...readinessInput, cwd: host.paths.cwd }, probeAcpRegistryConfiguration) in the ACP Registry driver.
• ProviderHost.paths.cwd is config.cwd, i.e. the directory the server/desktop app was started from, not the selected project.
• The composer reads skills/commands from the provider snapshot (resolveProviderSkillsForCwd), so the wrong cwd is baked into the picker before any thread session exists.

Notes

• opencode exposes real skills through its own CLI API (/api/skill, used by the built-in opencode driver), not as $-prefixed ACP commands, so even with a correct cwd only command-backed entries appear for ACP providers.
• AntigravityDriver already does per-workspace enrichment via snapshotForCwd(cwd, skills); ACP providers have no equivalent.

Suggested fix

1. Probe ACP providers with the project/thread cwd and re-probe per workspace (as Antigravity does), instead of the server cwd.
2. Optionally add skill discovery for ACP providers on top of the command list, so real skills are available rather than only $-prefixed commands.

Version

T3 Code v0.1.2, Linux desktop build. Agent: opencode 2.1.4 (opencode acp).