MCP connection for CodeShellManager

[AThraen]

So you from within Claude can control codeshellmanager. Like add terminals, clone terminals, sleep sessions, reorder them, etc.

[AThraen]

This was generated by AI during triage.

Extended scope & proposed plan

Expose CodeShellManager as a local MCP server so Claude Code (or any MCP client) can drive the GUI — create / close / sleep / wake / move sessions, read output, search history, and react to alerts — without the user having to leave the conversation.

Transport & auth

• In-process HTTP MCP server on 127.0.0.1, random free port, started by the WPF app on launch when enabled. Claude Code supports HTTP MCP servers natively, so no stdio shim required.
• On start, write the URL + a freshly rotated bearer token to %AppData%/CodeShellManager/mcp.json. Settings gets a "Copy claude mcp add command" button that templates the right invocation.
• Loopback-only listener; bearer required on every request. App is single-instance, so port collisions are not a concern.
• Off by default. Toggle in Settings → "Expose MCP server (experimental)". Driving a GUI from an agent is intrusive, so opt-in is the right default.

Library

• ModelContextProtocol.AspNetCore (official MS SDK) hosted alongside the WPF message loop. Kestrel runs on a background thread; all calls into SessionManager / MainWindow marshal through Dispatcher.InvokeAsync since neither is thread-safe today.

Tool surface (v1)

Sessions

• list_sessions — id, name, command, folder, status, alert/waiting flags, group, git branch, IsDormant, IsRemote
• create_local_session — name, folder, command, args, group_id, color
• create_remote_session — SSH fields (SshUser, SshHost, SshPort, SshRemoteFolder)
• clone_session — from existing id, same folder/command, new name
• close_session, sleep_session, wake_session
• rename_session, move_session (new index), set_active_session

Groups (depends on #24 landing — wire the existing SessionGroup model into the UI first)

• list_groups, create_group, rename_group, assign_session_to_group

I/O

• send_input — text to PTY, optional +enter. Uses TerminalBridge.SendToTerminal (Terminal/TerminalBridge.cs:319), already thread-safe.
• read_recent_output — last N lines from the ANSI-stripped SQLite index per session
• search_output — wraps SearchService.SearchAsync (Services/SearchService.cs:137)

App-level

• get_alerts — sessions currently NeedsAttention / IsWaitingForInput / IsWaitingForApproval
• get_layout / set_layout — Single, TwoByOne, TwoByTwo, etc.
• focus_window — bring CSM to front (handy when an alert fires)

Threading & state

• SessionManager is not thread-safe — every mutation goes through Dispatcher.InvokeAsync so existing events (SessionAdded / SessionRemoved / SessionsChanged) stay UI-thread.
• LaunchSessionAsync / SleepSession / WakeSessionAsync already assume UI thread — same treatment.
• SearchService and the SQLite output index are already off-UI-thread — call directly.
• Persistence: any mutating tool call ends with the standard MainViewModel.SaveStateAsync() so changes survive restart (honoring --clean).

Out of scope (v1)

• Streaming PTY output to the MCP client (would be an MCP resource subscription in v2 — useful but adds shape we don't need yet).
• Remote / cross-machine MCP — stays loopback.
• Letting MCP clients install new presets, change appearance, edit state.json directly, or read files outside the search index.
• Notifications to the MCP client (an MCP server can send notifications, but no current client wires them in usefully — revisit later).

Phases

1. Read-only first. list_sessions, get_alerts, read_recent_output, search_output, list_groups, get_layout. Lets us validate transport + auth + dispatcher marshalling with zero blast radius.
2. Session CRUD. Create / close / clone / sleep / wake / rename / move / set-active. Surfaces all the Dispatcher marshalling concerns.
3. I/O write. send_input — the highest-risk tool (an agent can type into another agent's terminal), gated behind a per-session confirmation toggle in Settings.
4. Layout + focus.
5. Polish. "Copy claude mcp add command" button, status indicator in toolbar showing whether MCP is enabled and connected, audit log of recent MCP tool calls (already half-built via the FTS5 indexer concept).

Open questions

• Per-tool confirmation? send_input and close_session are particularly footgun-prone. Could surface a Settings option: "Require confirmation for destructive MCP calls" → an in-app toast with allow/deny.
• Should send_input need to declare intent in a structured way ("command" vs "approval" vs "text") so we can show the user why something is being typed?
• Multi-client: if the user adds the MCP server to multiple Claude instances, do we want any kind of identity / per-client audit?

[AThraen]

This was generated by AI during triage.

Superseded in substance by #132, which specifies this ask (drive CSM from inside a session: create/sleep/wake/close/reorder/focus) as the fleet namespace of a single CSM-hosted MCP server, alongside self and the chat tools from #125.

Left open pending a maintainer call: close this as absorbed and keep #132 as the umbrella, or keep this one as the umbrella and treat #132 as its spec.