Summary

Basic Memory can fail to connect to Copilot CLI over local stdio when modern MCP discovery is delayed. Copilot times out its server/discover probe and sends legacy initialize on the same stream. The Python MCP SDK has selected the modern protocol from the opening request and rejects the later handshake with -32022.

Both protocols work individually. This is an interoperability/startup-readiness report, not a claim that BM's database or modern MCP support is intrinsically broken. Related client-side report: github/copilot-cli#4888.

Versions at the time of reproduction

Observed on 2026-10-09:

• Windows; local stdio transport and SQLite, without cloud routing.
• Copilot CLI: 1.0.95-0.
• Installed Basic Memory distribution: 0.23.3.dev8; bm --version prints 0.23.2.
• FastMCP: 4.0.0b1.
• Python MCP SDK: 2.2.0.
• Python used by the BM environment: 3.14.3.

Observed failure

failed to initialize MCP client: JSON-RPC error: -32022:
connection is serving the 2026-07-28 protocol; the initialize handshake is not accepted
{"supported":["2026-07-28"],"requested":"2025-11-25"}

BM's local database migrations and project initialization completed. A fresh, fast-starting Copilot connection to the unchanged BM configuration exposed all 21 tools successfully. Direct legacy initialization also succeeded, and direct modern discovery returned a valid result.

I have not isolated what delayed or invalidated discovery in the original failing session. The controlled reproduction below produces the same failure without requiring a particular dataset.

Controlled reproduction

1. Configure Copilot to launch the existing bm mcp stdio server.
2. Put a diagnostic stdio relay between Copilot and BM. Start BM normally, but buffer inbound client messages for 35 seconds before forwarding them unchanged. This emulates a slow-starting server; the relay does not fabricate responses or rewrite protocol fields.
3. Use a fresh Copilot runtime and perform live tool discovery, with the tool snapshot cache disabled.
4. Observe the message sequence below.

Sanitized trace; times are relative to connection startup:

Repeating with the server's ordinary MCP timeout set to 60000 did not change the approximately 10-second discovery fallback or prevent failure.

A diagnostic handshake-only launch of the same installed BM server avoided the failure under the identical 35-second delay and exposed all 21 tools. Existing notes were readable through it. I have not adopted that workaround: a supported solution retaining modern MCP is preferable.

Expected behavior and possible resolutions

A delayed modern discovery response should not leave BM permanently unavailable because the client and server have selected different protocol eras on the same stream.

Possible approaches, offered for maintainer guidance rather than as confirmed fixes:

1. Client-side recovery: after a discovery timeout, retry modern discovery appropriately or reopen the stdio transport before attempting a legacy handshake. Adopt successful modern discovery results rather than initializing that stream again. The linked Copilot issue tracks this boundary.
2. BM startup/readiness: where feasible, answer modern discovery promptly without waiting for heavyweight initialization, while advertising capabilities accurately and preventing premature tool execution.
3. Supported configuration: document or expose an applicable discovery/readiness control. The normal tool timeout is not controlling the initial probe in this client.

Does BM have a supported modern-preserving remedy or relevant newer dependency/runtime fix, or should resolution be coordinated entirely with Copilot and the Python MCP SDK? I am not requesting a dependency downgrade or legacy-only operation as the default.