Feature request: conversation-scoped Remote sessions for concurrent AI chats

[cxhttt233]

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.

[josh87523]

Additional evidence for the metadata-forwarding option with Desktop Commander 0.2.51. The earlier comparison used real ChatGPT conversations; a 2026-09-20 recheck used the existing Remote connector from Codex.

Our use case is a per-conversation bootstrap check: require a successful read of a workspace's root AGENTS.md before forwarding workspace operations. A device-wide flag would incorrectly unlock unrelated conversations.

Observed locally:

• In 107 recent Remote calls, metadata contained transport, clientInfo, origin_instance, is_internal_user, and device_app_version, but no conversation identifier.
• A fresh, read-only get_file_info call on 2026-09-20 was matched against only the newly appended device log bytes. It again contained exactly the five metadata keys above, with no openai/session or openai/subject. This Codex-host check is not a new ChatGPT browser E2E test.
• The device fetches the complete mcp_remote_calls row. handleNewToolCall passes its metadata to callClientTool, which forwards it as _meta: { remote: true, ...metadata }.
• In a separate metadata-only FastMCP endpoint, five real ChatGPT calls confirmed that _meta["openai/session"] was stable across calls and revisiting a conversation, and differed between two conversations: A1=A2=A3, B1=B2, A!=B. Transport session identity was not a reliable substitute.

OpenAI documents openai/session as a conversation identifier:
https://developers.openai.com/plugins/reference#_meta-fields-the-client-provides

Could the hosted Remote MCP service preserve the platform-provided openai/session and, where available, openai/subject in the device-bound call metadata, alongside an authoritative binding to the existing authenticated Remote account? The local forwarding code already preserves metadata, so this may enable the narrow use case while retaining the current login, private transport and execution engine.

For the guard to enforce isolation, the provenance contract also matters: how can the device distinguish ChatGPT-provided identity from arbitrary caller-supplied metadata? A verified source/account context must be produced by the trusted service and must not be overridable by tool arguments or unverified incoming metadata. A transport Mcp-Session-Id, device ID or per-call ID cannot stand in for the actual ChatGPT conversation.

Suggested verification: same authenticated user/device, two conversations; repeated calls retain their conversation value and the two values differ. Missing metadata must remain missing, without falling back to a device-wide identifier. The field is a grouping key, not authentication, and should be scoped to the authenticated account/device. No raw conversation identifiers or credentials need to be logged.

This identifies the missing field at the device boundary; we have not inspected the hosted service implementation or established exactly where it is dropped upstream.