Context
The ax_click / ax_set_value tools introduced on feat/ax-dispatch hold their snapshot state on MacOSDevToolsServer as a single current snapshot. That matches the CDP side's ownership pattern and works for the current single-client-per-server deployment.
The motivation behind the AX dispatch work — non-disruptive per-agent virtual cursors — eventually implies multiple agents operating on the same server in parallel. With one shared current snapshot, any agent calling take_ax_snapshot invalidates every other agent's pending uids. That is a correctness concern, not just a UX inconvenience, once a multi-agent deployment is attempted.
Problem
MacOSDevToolsServer.ax_session: Arc<AxSession> holds one RwLock<Option<AxSnapshot>>.- All callers of a given server process share that snapshot and its generation counter.
- Agent A's fresh snapshot promotes the generation and drops Agent B's refs.
Proposed direction
Per-MCP-session state — each rmcp session gets its own AxSession. Requires:
- Checking rmcp's current session-context / request-scoped state APIs (as of rmcp 0.2 we use today).
- Keying the session map by rmcp session id or connection id, whichever is stable.
- A session-drop hook that releases
AXRefs when the MCP connection closes (otherwise refs leak until process exit).
Non-goals
- Multi-process isolation (already free — one server per process).
- Cross-session uid sharing (not needed; uids are opaque per session).
References
- Design doc:
.claude/plans/2026-04-18-ax-dispatch-design.md (branch feat/ax-dispatch), §Scope > Out of scope, §Open questions
- External design review:
internal_docs/design-reviews/2026-04-18_ax-dispatch.md, finding D1.C2
- Existing single-snapshot ownership precedent:
src/cdp/mod.rs:25 (last_ax_snapshot: Option<SnapshotMap>)
Context
The
ax_click/ax_set_valuetools introduced onfeat/ax-dispatchhold their snapshot state onMacOSDevToolsServeras a single current snapshot. That matches the CDP side's ownership pattern and works for the current single-client-per-server deployment.The motivation behind the AX dispatch work — non-disruptive per-agent virtual cursors — eventually implies multiple agents operating on the same server in parallel. With one shared
currentsnapshot, any agent callingtake_ax_snapshotinvalidates every other agent's pending uids. That is a correctness concern, not just a UX inconvenience, once a multi-agent deployment is attempted.Problem
MacOSDevToolsServer.ax_session: Arc<AxSession>holds oneRwLock<Option<AxSnapshot>>.Proposed direction
Per-MCP-session state — each rmcp session gets its own
AxSession. Requires:AXRefs when the MCP connection closes (otherwise refs leak until process exit).Non-goals
References
.claude/plans/2026-04-18-ax-dispatch-design.md(branchfeat/ax-dispatch), §Scope > Out of scope, §Open questionsinternal_docs/design-reviews/2026-04-18_ax-dispatch.md, finding D1.C2src/cdp/mod.rs:25(last_ax_snapshot: Option<SnapshotMap>)