In prompt mode, an extension tool's permission request waits forever instead of being denied, and --allow-tool can't name an extension tool #5381

Describe the bug

In prompt mode (copilot -p), when the model calls a tool that an extension registers, the CLI raises a custom-tool permission request that nothing answers, so the run waits until it is killed. Prompt mode's permission handler returns early for that kind (if (resolvedByHook || kind === "custom-tool") return; in cli-main.js). Other requests that need approval in prompt mode are denied at once with denied-no-approval-rule-and-could-not-request-from-user, as the permissions help says they should be.

--allow-tool with the extension tool's name doesn't match the request either, and the permissions help documents no rule pattern for extension tools. Only --allow-all-tools works, so a scripted check of one extension tool has to allow every tool.

Affected version

GitHub Copilot CLI 1.0.108-1 (prerelease). The same early return is in 1.0.107.

Steps to reproduce the behavior

1. Install a plugin or user extension that registers a tool, such as probe_ping.
2. Run copilot -p "Call probe_ping once.". The run waits; events.jsonl shows permission.requested with kind: "custom-tool" and no permission.completed until the process is killed.
3. Run it again with --allow-tool probe_ping. Same result.
4. Run it with --available-tools probe_ping --allow-all-tools. The tool runs.

Expected behavior

Prompt mode denies an extension tool request that no rule allows, as it does for other kinds, and --allow-tool accepts a pattern for one extension tool.

Additional context

• macOS on Apple silicon (arm64).
• Reproduced on 2026-11-07 with an extension tool. With no rule, the run waited three and a half minutes until it was cancelled. With --allow-tool naming the tool, it waited the same way. With --available-tools naming the tool and --allow-all-tools, the tool ran.