Feature request: conversation-scoped Remote sessions for concurrent AI chats
Problem
Desktop Commander Remote currently maps one physical machine to a single remote execution identity (deviceId). This is fine for one AI conversation, but multiple ChatGPT / AI conversations using the same computer concurrently are not conversation-scoped: they share one device identity, activity/log context and lifecycle.
Expected behavior
One authenticated physical device should be able to host multiple lightweight logical Remote sessions. Each logical session should have independent call routing, activity/log state and lifecycle, while sharing the same local MCP engine and physical machine. The physical gateway should remain the single authentication / refresh-token authority.
Working prototype
I built and tested a compatibility prototype here: https://github.com/cxhttt233/desktop-commander-claude-style
The prototype allocates a temporary logical deviceId per AI conversation, gives each session its own Realtime Presence and visible worker/status window, shares one local MCP engine, never copies refresh tokens, and removes only that logical session when its worker closes. Multiple ChatGPT conversations were tested concurrently on the same Windows machine.
Suggested upstream direction
The temporary-device approach is a compatibility layer. A cleaner upstream model would be a first-class logical session, for example (device_id, session_id, call_id), or a stable client/session identifier passed through MCP metadata.
That would avoid pretending every conversation is a physical device and would remove the initial redirect/retry step required by the prototype.
This becomes increasingly useful for parallel agents, multiple ChatGPT windows, and other concurrent Remote clients.
Source: wonderwhy-er/DesktopCommanderMCP