Problem
DOMShell's kernel keeps a single global shell state — current directory, current tab, DOM cursor, and group binding — shared by every client. Open DOMShell side panels in two Chrome windows, or connect two MCP agents, and they all drive that one cursor: one console's cd moves the other; near-simultaneous commands interleave and can act on the wrong tab.
Proposed direction
Give every DOMShell client its own independent session — its own current directory, current tab, DOM cursor, %here%, and group binding:
- Phase 1 — side-panel consoles. Each console (keyed by its Chrome window) is its own session. Two windows = two independent shells, each holding its own position. Includes serialized command execution so commands never race.
- Phase 2 — MCP. Each MCP connection is a session bound to its own tab group, so multiple agents (e.g. Claude Code + Gemini CLI) can work concurrently without interfering with each other or with the user.
Backward-compatible: a single console / single MCP session behaves exactly as today.
Related
Follows on from #32 (tab-group isolation). Tab groups isolate an agent's tabs; this isolates each client's shell state.
Problem
DOMShell's kernel keeps a single global shell state — current directory, current tab, DOM cursor, and group binding — shared by every client. Open DOMShell side panels in two Chrome windows, or connect two MCP agents, and they all drive that one cursor: one console's
cdmoves the other; near-simultaneous commands interleave and can act on the wrong tab.Proposed direction
Give every DOMShell client its own independent session — its own current directory, current tab, DOM cursor,
%here%, and group binding:Backward-compatible: a single console / single MCP session behaves exactly as today.
Related
Follows on from #32 (tab-group isolation). Tab groups isolate an agent's tabs; this isolates each client's shell state.