Problem
In ZCode desktop, several slash-commands documented for Claude Code are not available. Most notably:
/hooks — read-only browser for configured hooks (would let users verify their config without restarting).
/mcp — MCP server status, connection check, reconnect.
/plugins — browse/install/manage plugins.
Currently the only way to manage these is through Settings → MCP / Plugins GUI, which works for enable/disable but doesn't show runtime status (connection state, hook execution log, hook config validation errors).
Why this matters
I just spent ~3 hours debugging why my UserPromptSubmit hook wasn't firing. Root cause turned out to be an invalid args field in config.json that silently disabled the entire hooks section (see issue #32, where I left a detailed comment). A /hooks command showing:
- Which hooks are registered.
- Their matchers.
- The last execution result (success/failed/not-triggered).
would have caught this in 30 seconds instead of 3 hours.
Similarly, /mcp showing live connection state would help diagnose the MCP subprocess leak (#104) — users could see "5 desktop-commander processes running" without leaving the chat.
What exists today (verified on ZCode 3.3.6, Windows 11 Pro)
- Settings → MCP Servers (GUI): add/edit/delete/enable/disable.
No runtime status, no "test connection" button.
- Settings → Plugins (GUI): enable/disable, marketplace browse.
No hook viewer.
~/.zcode/cli/log/zcode-YYYY-MM-DD.jsonl: contains config.file.invalid, hook.run.failed, mcp.configured_servers.connect.completed events with detailed diagnostics. But this is a JSONL file users have to grep manually — not friendly.
Proposal
Add slash-commands (or in-chat UI) that surface the runtime state already being logged:
/hooks — list registered hooks with last-execution status.
/mcp — list MCP servers with connection state and process count.
/plugins — list installed plugins with enabled state and last error.
These are read-only views over data ZCode already collects. Would significantly improve power-user debuggability without changing the underlying engine.
Related
Environment
- ZCode 3.3.6, Windows 11 Pro.
- 6 MCP servers, 3 custom hooks, 4 plugins.
Thanks!
Problem
In ZCode desktop, several slash-commands documented for Claude Code are not available. Most notably:
/hooks— read-only browser for configured hooks (would let users verify their config without restarting)./mcp— MCP server status, connection check, reconnect./plugins— browse/install/manage plugins.Currently the only way to manage these is through Settings → MCP / Plugins GUI, which works for enable/disable but doesn't show runtime status (connection state, hook execution log, hook config validation errors).
Why this matters
I just spent ~3 hours debugging why my UserPromptSubmit hook wasn't firing. Root cause turned out to be an invalid
argsfield in config.json that silently disabled the entire hooks section (see issue #32, where I left a detailed comment). A/hookscommand showing:would have caught this in 30 seconds instead of 3 hours.
Similarly,
/mcpshowing live connection state would help diagnose the MCP subprocess leak (#104) — users could see "5 desktop-commander processes running" without leaving the chat.What exists today (verified on ZCode 3.3.6, Windows 11 Pro)
No runtime status, no "test connection" button.
No hook viewer.
~/.zcode/cli/log/zcode-YYYY-MM-DD.jsonl: containsconfig.file.invalid,hook.run.failed,mcp.configured_servers.connect.completedevents with detailed diagnostics. But this is a JSONL file users have to grep manually — not friendly.Proposal
Add slash-commands (or in-chat UI) that surface the runtime state already being logged:
/hooks— list registered hooks with last-execution status./mcp— list MCP servers with connection state and process count./plugins— list installed plugins with enabled state and last error.These are read-only views over data ZCode already collects. Would significantly improve power-user debuggability without changing the underlying engine.
Related
argsfield regression.zcode-guide:diagnosing-hooks,diagnosing-mcp,diagnosing-plugins— already document the intended commands.Environment
Thanks!