No way to list installed hooks (plugin-bundled or individual) — MCP has `copilot mcp list`, hooks have no equivalent

[ken-jo]

Describe the bug

copilot plugin --help says plugins extend Copilot CLI with "additional skills, agents, hooks, MCP servers, and LSP servers". But while MCP servers are enumerable (copilot mcp list/copilot mcp get, the /mcp TUI command, and /env), there is no surface at all that lists installed hooks — neither plugin-bundled nor individually-configured ones.

• No copilot hook/copilot hooks CLI command exists (both fall through: error: Invalid command format. Did you mean: copilot -i "hooks list"?). Top-level commands are only: completion, help, init, login, mcp, plugin, update, version.
• No /hooks TUI command (copilot help commands has zero hook mentions).
• /env's documented scope is "instructions, MCP servers, skills, agents, plugins, LSPs, extensions" — hooks are the one plugin component type left out.
• copilot plugin list only prints the plugin name/version, with no component breakdown.

Across all help topics, the word "hook" appears only in copilot help config (the hooks config key and disableAllHooks toggle).

Affected version

GitHub Copilot CLI 1.0.63

Steps to reproduce

1. Create a local plugin dir with plugin.json ({"name":"testplug","version":"0.1.0"}) and a hooks.json defining a preToolUse command hook.
2. copilot plugin install ./testplug → "Plugin "testplug" installed successfully." The hook lands at ~/.copilot/installed-plugins/_direct/testplug/hooks.json (note: ~/.copilot/hooks/ is never created).
3. copilot plugin list → only • testplug (v0.1.0) — no mention of the bundled hook.
4. Try to confirm the hook some other way: copilot hook list, copilot hooks list → error: Invalid command format. There is no /hooks TUI command either.
5. Compare with MCP: copilot mcp add indiv-mcp -- echo hello then copilot mcp list → User servers:\n indiv-mcp (local), and copilot mcp get labels the source. MCP has a list surface; hooks have none.

Expected behavior

A way to enumerate installed hooks, the way MCP servers can be listed — e.g. a copilot hook list (with a source label: User / Plugin, mirroring copilot mcp list's sources), and/or a /hooks TUI command, and/or adding hooks to /env's output. Since copilot plugin --help already lists hooks as a first-class plugin extension type, they should be observable like the other types.

Additional context

Why this matters: because nothing tells a user that a plugin already ships a hook, someone who installs a hooks-bundling plugin and then also adds the same hook to ~/.copilot/config.json (the documented user-level inline-hook surface) ends up with the same event hook registered twice, in two mutually-invisible locations, with no command to detect or de-dupe it. The only way to audit installed hooks today is to manually read the plugin's hooks.json and config.json by hand.

(Filed separately from the hook-firing issues #2540 / #3659 — this is purely about there being no way to list/see installed hooks, regardless of whether they fire.)

[ken-jo]

Confirmed this end-to-end on 1.0.63, and worth nailing down the half the report deliberately brackets ("regardless of whether they fire"): the bundled hook does fire — there's just nothing that tells you it exists.

Minimal repro: a plugin with plugin.json + a hooks.json declaring one preToolUse command hook (echo MARKER >> /tmp/probe.log), copilot plugin install ./probe, then a normal session that runs a tool (copilot -p "run: echo hello" --allow-all). The hook ran on every tool call — the marker file got written, and with --log-level all the CLI's own log confirms it: [DEBUG] Executing hook: echo MARKER ....

Then every user-facing surface comes up empty: plugin list prints only • probe (v0.1.0), copilot hook list/hooks list → error: Invalid command format, there's no /hooks command, and /env's scope leaves hooks out. So the hook is silently active and silently invisible at the same time — you only find it by hand-reading installed-plugins/_direct/<plugin>/hooks.json. (Also confirmed ~/.copilot/hooks/ is never created by a plugin install — the hook lives only in the plugin's cache dir.)

That's the strongest argument for a copilot hook list with a source label (User / Plugin), mirroring copilot mcp list: a firing, effective hook currently has zero discoverable footprint.