[FEATURE] Remote Control: allow MCP server reload / process restart from a remote session

Summary

When driving Claude Code from a Remote Control session, there is no way to refresh MCP server tool schemas or restart the Claude Code process — the operations that would do so (\/mcp\, killing + relaunching \claude\) all require physical access to the host machine.

For developers iterating on a custom MCP server (rebuild → exercise new tools → repeat), this forces a context switch to the host between every iteration, which defeats the value proposition of Remote Control.

Reproduction

1. Start \claude\ in remote-control mode on host A.
2. Connect from device B (different machine, browser / mobile).
3. Rebuild a custom MCP server's binary on host A while the session is live.
4. From device B, attempt to refresh MCP tool schemas — there is no remote-eligible path:

• \/mcp\ is local-only (documented).
• There is no \/mcp reload\ or \/reload-mcp\ command.
• There is no remote command to restart the Claude Code process; even if one existed, the remote session would need to auto-reconnect after the process respawned.

1. The only way forward is to physically return to host A, kill + relaunch \claude\, and reconnect from device B.

Proposed

Any one (or combination) of the following would close the gap, ranked by my preference:

1. Make MCP reload remote-eligible. A non-interactive variant of \/mcp\ (e.g. \/mcp reload\, or a flag-driven form) that re-handshakes the MCP children without an interactive picker. This would also benefit related issues:

• #46426 — Feature request: hot-reload MCP servers without restarting the session
• #40059 — Allow reloading MCP servers without restarting the session
• #36847 — SIGHUP handler for config and plugin reload (headless-friendly)

1. Remote process restart with auto-resume. A remote command that triggers \claude\ to re-exec itself (or a wrapper that respawns it), with the Remote Control session auto-reconnecting to the new process. Mirrors the precedent of #39724 (\/model\ switching in remote-control).
2. HTTP / WS endpoint on the local Claude Code process that the Remote Control bridge can call to issue an MCP reload command on the user's behalf, gated by the same auth as the Remote Control session itself.

Context / why now

Custom MCP servers — including community projects like vaultpilot-mcp and many others driving the recent growth in MCP usage — ship fresh schemas with every PR. The "remote drives the host" pattern is exactly what Remote Control sells, but the iteration loop today is "remote → can't reload → walk to host → restart → walk back → continue", which is meaningfully worse than just developing locally.

Related

• #46426 — Feature request: hot-reload MCP servers without restarting the session (general; not remote-specific)
• #40059 — Allow reloading MCP servers without restarting the session (general)
• #36847 — feat: SIGHUP handler for config and plugin reload (headless-friendly alternative)
• #39724 — [FEATURE] Allow /model switching in remote-control sessions (precedent: expand a local-only command to remote-eligible)
• #45989 — Remote-control: web client never delivers work to bridge after service restart (related infra: how Remote Control survives process churn today)

If reload + auto-resume already exists and I missed the doc page, happy to close — but the answer I got from the in-product help was "you have to restart locally; \/mcp\ is local-only."