tracking(serve): Track ACP gaps for cd, permissions, trust, lsp, and setup-github

Progress

• /lsp — Added acp to supportedModes, ACP clients can invoke /lsp directly. → fix(cli): enable /lsp in ACP mode #5689
• /permissions — Added structured REST API: GET /workspace/permissions (read) + POST /workspace/permissions (update rules), registered in ACP route table. → feat(cli): Add workspace permissions rules API #5743, feat(serve): Add daemon workspace voice and control APIs #5765
• /trust — Added GET /workspace/trust (query status) + POST /workspace/trust/request (request trust change), registered in ACP route table. → feat(serve): Add daemon workspace voice and control APIs #5765
• /setup-github — Added POST /workspace/setup-github ACP endpoint, registered in ACP route table. → feat(serve): Add daemon workspace voice and control APIs #5765
• /cd — No daemon/ACP-safe session cwd change mechanism exists. The command remains interactive-only with no equivalent REST endpoint or ACP route.

What would you like to be added?

Please track and address the remaining daemon/ACP capability gaps for these CLI slash commands:

This should be tracked separately from the broad daemon backlog because these commands are not covered by generic slash-command passthrough. Sending them through:

POST /session/:id/prompt
{"prompt":[{"type":"text","text":"/cd /path"}]}

does not execute the command successfully. The prompt is accepted, but the ACP slash-command path filters commands by mode and rejects commands that do not support acp.

Why is this needed?

Remote clients should be able to determine which CLI capabilities are intentionally unavailable, which have structured daemon replacements, and which are missing daemon/ACP capabilities.

Today these five commands create ambiguity:

• They look like ordinary slash commands to users.
• They can be sent through the same /prompt shape used by ACP-compatible commands.
• The request may be accepted asynchronously, but the command later fails because it is not supported in ACP mode.
• Some nearby capabilities exist, such as session creation with cwd, permission mediation, /status, file write, or optional shell execution, but those are not equivalent to the CLI command behavior.

Tracking them together would give downstream web-shell, IDE, and SDK clients a concrete compatibility checklist instead of treating each command as an isolated surprise.

Additional context

Related issues:

• tracking(serve): daemon capability gaps & prioritized backlog (post v0.16-alpha) #4514 tracks the broader qwen serve HTTP/SSE backlog and explicitly distinguishes ACP-compatible slash passthrough from capabilities that need dedicated HTTP/SSE/SDK support.
• web-shell: 13 个 CLI slash commands 未支持 #4809 tracked a broader web-shell slash-command gap list, but this request narrows the scope to five commands that still need a clear daemon/ACP decision.

Observed behavior:

• Built-in commands without acp support are filtered out of the ACP command set.
• Known commands that are filtered out return an unsupported slash-command result rather than falling through as normal model prompts.
• Dialog-returning commands such as /permissions and /trust need more than simply adding acp to supportedModes.
• /setup-github also needs an ACP-safe result shape or a dedicated remote workflow because generic file writes do not reproduce the command's release lookup and setup behavior.

Suggested acceptance criteria:

• The daemon exposes an explicit support decision for each of the five commands.
• Commands that remain unsupported in ACP are documented with a recommended remote-client alternative.
• Commands that should be supported remotely have a structured route, ACP method, SDK helper, or ACP-safe slash implementation.
• Web-shell and SDK clients can preflight support without sending a command that later fails asynchronously.

POST /session/:id/prompt
{"prompt":[{"type":"text","text":"/cd /path"}]}