Implement SEP-2260: Require Server requests to be associated with a Client request

[felixweinberger]

This is a tracking issue for implementation of SEP-2260.

[mattzcarey]

Status — SEP-2260 (Server requests associated with Client requests)

Track: A (core, sequential spine) — starts now (current spec, doesn't require 2026-06 mode)
Spec: seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.md · merged & marked Final in spec#2730

What's done

• Nothing in main yet.
• Closed exploration: feat(server): handleHttp() per-request entry, SessionCompat, dual-conformance #2058 (handleHttp() per-request entry, SessionCompat, dual-conformance) — Felix's r3-handlehttp branch laid the per-request HTTP entry-point groundwork the bugfix will land into.

Outstanding (acceptance criteria from the spec page)

• R-2260-1 (wire): s→c requests (roots/list, sampling/createMessage, elicitation/create) MUST only be sent on the POST-response SSE stream of an originating client request.
• R-2260-3 (sdk): no API for unsolicited s→c.
• R-2260-4 (wire): SSE keepalive SHOULD be used during nested waits.
• R-2260-5 (wire): client receiving an orphan s→c request SHOULD respond -32602.
• R-2260-6 (wire): GET-initiated standalone SSE streams MUST NOT carry s→c requests (notifications/pings only).
• R-2260-7 / 8 (guidance): timeouts accommodate human-in-the-loop delays; ping exempt.

Fixes long-standing bugs #963 and #1167.

Test backlog

• [DRAFT] test(e2e): 2026-06 spec backlog — SEP-2260 + SEP-2575/2567 as expected-fail stubs #2180 (DRAFT) adds the 2260 + 2575/2567 acceptance criteria to the v2 e2e suite as known-failure stubs — adopt as the conformance ratchet for this issue.

Open spec PRs to watch

• None active (SEP marked Final 2026-05-15).

Suggested first PR

Standalone bugfix (~90 LOC per the spec-page sequencing plan): ensure ctx.elicit / ctx.sample only emit on the originating request's response stream, never on a separate channel. Lands on current-spec code, doesn't need 2026-06 mode.