ACP sessions can access MCP tools supplied by other sessions

Description

ACP session/new.mcpServers are registered on the OpenCode instance. When one ACP process hosts multiple sessions, a session can therefore receive MCP tools supplied by another session. The foreign tool can carry that other session's endpoint and headers. This is related to #32371, but also affects concurrently open sessions. ### Plugins None ### OpenCode version Current dev (69f2cbaa3ab8) ### Steps to reproduce 1. Start one opencode acp process. 2. Open two ACP sessions in the same cwd with distinct mcpServers names and endpoints. 3. Prompt the first session after both are open. 4. Observe that tools from the second session are included in the first session's OpenCode tool registry. ### Screenshot and/or share link N/A ### Operating System Windows 11 ### Terminal Windows Terminal

ACP session-level MCP semantics

According to the ACP Session Setup specification, a session represents a specific conversation or thread. Each session maintains its own context, history, and state so that one Agent can host multiple independent interactions.

MCP server connection details are supplied as part of session/new, session/load, and session/resume, rather than during global Agent initialization. The Agent connects to those servers while establishing that session. These details may contain session-specific commands, environment variables, endpoints, and HTTP headers.

The specification also states that session/close must cancel ongoing work and free resources associated with that active session.

Although the specification does not contain a single explicit sentence saying "MCP registrations MUST be isolated by session," its ownership and lifecycle model imply the following behavior:

• MCP servers supplied while establishing session A belong to session A.
• Establishing session B must not change the MCP clients, tools, endpoints, or credentials visible to session A.
• Two sessions may use the same human-readable MCP server name with different connection details without colliding.
• Closing session B should release only session B's MCP connections.
• A session created without an MCP server should not inherit that server from another session.

The observed implementation violates this model because ACP-provided MCP servers are registered in an instance-level registry shared by sessions using the same working directory. Registrations are keyed by server name rather than by session ownership. Consequently, a later session can replace or expose its MCP client to an earlier session, including its endpoint and request headers, and closing the owning session does not remove the leaked registration.

This is therefore not only a tool-list presentation issue. It is a cross-session ownership and lifecycle isolation issue for ACP-provided MCP resources.