Title: ACP agent ignores custom JSON‑RPC methods and only exposes internal tool list

[rcarmo]

Describe the bug

Summary:
Running Copilot with --acp inside an ACP harness (https://github.com/rcarmo/vibes), the agent refuses to issue custom ACP JSON‑RPC method calls (e.g. vibes/store_media_file) and instead reports only its internal tool schema (bash, rg, etc.). This prevents ACP clients from adding custom tool capabilities.

Request:
Please confirm whether Copilot’s ACP runtime supports arbitrary JSON‑RPC method calls from the agent. If yes, what is the correct mechanism for the model to emit custom method calls? If no, can support be added?

Affected version

GitHub Copilot CLI 0.0.413-0.

Steps to reproduce the behavior

1. Run Vibes with VIBES_ACP_AGENT="copilot --acp --model gpt-5.2-codex" VIBES_PERMISSION_AUTO_APPROVE=true vibes
2. Prompt agent with explicit instruction to send a JSON‑RPC request for vibes/store_media_file.
3. Observe logs: no request is emitted; agent only lists internal tools.

Expected behavior

When instructed, the ACP agent should emit a JSON‑RPC request such as:

json {"jsonrpc":"2.0","id":1,"method":"vibes/store_media_file","params":{"path":"artifacts/report.pdf"}}

and then include the tool result’s content blocks in the final response.

Additional context

Actual behavior:
Agent responds with: │ “I currently see these callable tools in this session: bash, write_bash, read_bash, … I don’t currently see native vibes/* tools │ exposed in this runtime.”

No JSON‑RPC request is sent for vibes/* methods.

Why this is a problem:
ACP is designed to allow clients to implement custom methods. The agent appears to ignore or reject these methods and instead relies on its internal tool registry, making custom ACP integration impossible.

Environment:

• Vibes server with ACP enabled
• Agent command: copilot --acp
• ACP debug logging enabled
• No vibes/* JSON‑RPC requests observed in logs

[darthmolen]

Can independently confirm this behavior. I'm building a VS Code extension that wraps the Copilot CLI via ACP, and ran a systematic protocol spike against copilot --acp --stdio (CLI v0.0.394).

Test: Passed tools array in session/new params with a well-formed tool definition:

{
  "tools": [{
    "name": "get_weather",
    "description": "Get current weather for a city",
    "inputSchema": {
      "type": "object",
      "properties": { "city": { "type": "string" } },
      "required": ["city"]
    }
  }]
}

Result: The tools parameter is accepted without error (session/new succeeds, returns sessionId), but the agent cannot see or use the tool. When prompted to use get_weather, the agent responds: "I don't have access to a 'get_weather' tool. The tools available to me are for code development..."

The silent acceptance is particularly problematic — if the parameter were rejected with a validation error (like mcpServers does for wrong formats), clients would know immediately that custom tools aren't supported. Compare: passing an invalid mcpServers format returns a clear -32603 Internal error with a Zod validation trace showing exactly what's wrong.

This blocks any ACP client from implementing custom tool workflows (plan mode accept/reject, specialized integrations, etc.) without wrapping them as MCP servers.