Module commands 

Ex-commands owned by the Claude Code IDE peer.

:claude-code-start / :claude-code-stop control the IDE server’s lifecycle. Per feedback_mode_owns_its_surface, BOTH the binding (the command name) AND the handler body live in this crate: the apply closure captures the ClaudeCodeServerHandle and drives it directly (a non-blocking cmd_tx send), returning an Effect::Echo for user feedback. The host’s only role is calling register_claude_code_ex_commands once at boot.

The names are registered bare (no ex: namespace prefix), so they resolve directly via id_by_name on the : line with no host alias-table entry — the command surface is fully crate-owned. They are CommandKind::ExCommand, so they enumerate in completion / :apropos and obey the dashed + namespaced naming rule (like lsp-format).

Why an apply closure that captures a handle rather than a mode ActionHandler: the : line rejects CommandKind::Action (excommand.rs), and an ex-command apply (Fn(&ExCommandContext) -> Effect) gets no services, so it cannot reach the ActionHandlerRegistry. Capturing the subsystem handle is the mode-ownership-compliant route — it keeps the handler body in the crate without a new host Effect variant. See design §2.

Functions

register_claude_code_ex_commands

Register :claude-code-start / :claude-code-stop against registry, wiring each to server. Called once from editor boot.