Problem
DOMShell gives each MCP connection its own isolated session (#33). But MCP exposes no identity below the connection — clients like Claude Desktop multiplex every chat over a single connection, so two chats land in the same lane and share it.
Proposed direction
Add an optional group_id parameter to domshell_execute:
- omitted → the connection's current lane (stable — never spawns a new one)
"new" → create a fresh lane; the command runs in it; the new id is returned"<id>" → run in that lane
Every response echoes the group_id it ran in, so an agent always knows its lane. Two chats on one connection each pass their own id → isolated. And one agent can hand a session to another just by passing along the id.
The single-tool interface is preserved — one parameter, no new tools.
Related
Builds on #33 (multi-session DOMShell). #33 isolates per MCP connection; this isolates per agent-declared lane within a connection.
Problem
DOMShell gives each MCP connection its own isolated session (#33). But MCP exposes no identity below the connection — clients like Claude Desktop multiplex every chat over a single connection, so two chats land in the same lane and share it.
Proposed direction
Add an optional
group_idparameter todomshell_execute:"new"→ create a fresh lane; the command runs in it; the new id is returned"<id>"→ run in that laneEvery response echoes the
group_idit ran in, so an agent always knows its lane. Two chats on one connection each pass their own id → isolated. And one agent can hand a session to another just by passing along the id.The single-tool interface is preserved — one parameter, no new tools.
Related
Builds on #33 (multi-session DOMShell). #33 isolates per MCP connection; this isolates per agent-declared lane within a connection.