modelcontextprotocol / modelcontextprotocol/ext-apps
MCP Apps: No shared session identity between AppBridge and Model sub-connections
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2.9k
- Forks
- 387
- Avg merge
- 3h 21m
- Merged PRs (30d)
- 6
Description
MCP Apps: AppBridge and Model get separate session IDs — no way to correlate them
I'm building an MCP server with an MCP App (AppBridge iframe). The App UI needs to know what the Model is doing - e.g. when the Model kicks off a tool call, the App should show live progress.
The problem: Claude Desktop calls initialize twice, once for the AppBridge and once for the Model - so they end up with different Mcp-Session-Id values. My server generates a session ID on each initialize:
const headerSessionId = request.headers.get("Mcp-Session-Id");
const mcpSessionId =
headerSessionId ||
(jsonRpcRequest.method === "initialize" ? crypto.randomUUID() : null);
Since initialize fires twice, I get two UUIDs. Here's what the request log looks like:
| # | Method | Session ID | Origin |
|---|---|---|---|
| 1 | initialize |
eceb9a34… |
AppBridge |
| 2–6 | resources/list, tools/list, etc. |
eceb9a34… |
AppBridge |
| 7 | initialize |
913a52df… |
Model |
| 8 | tools/call |
913a52df… |
Model |
So when the Model calls a tool, the server stores state under 913a52df…. But the AppBridge queries using eceb9a34… - it never finds it.
I don't see a way in the spec to link these two sessions together. Is the dual-initialize intentional? If so, is there a planned way to share a conversation-level or connection-level ID across both sub-connections?
A previously working prototype also broke with this behavior, so this might be a recent change in Claude Desktop.
Environment: Claude Desktop/Claude Web
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No repository files or tests are named. Start by reviewing the MCP Apps session-handling and initialize behavior described in the request logs, then determine whether the two sub-connections are intentionally separate and what supported correlation mechanism, if any, should be specified; done means the session relationship and expected server behavior are resolved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100