fix(mcp): default container to authenticated userId when x-sm-project is absent (#792)

[teddyoweh]

Summary

Fixes #792. MCP sessions previously fell back to the hardcoded sm_project_default container inside SupermemoryClient when clients did not forward the x-sm-project header. Users who query their own container directly via /v3 and /v4 search (the userId-as-containerTag pattern documented in apps/docs/install.md) therefore could not see memories written through MCP — producing the empty-results symptom reported in the issue (direct API searches, MCP recall over OAuth, and hybrid searchMode all returning nothing while MCP writes succeeded).

MCP reads and writes are already symmetric through getClient(containerTag) in server.ts, so the divergence was purely in the default. This PR shifts the default for MCP sessions to authUser.userId, while still honoring an explicit x-sm-project header when clients do forward one.

Changes

• apps/mcp/src/index.ts: rename the header capture to headerContainerTag; after auth validation, compute const containerTag = headerContainerTag || authUser.userId and thread it through ctx.props before handing off to the MCP handler. Comment added explaining the rationale and linking to Claude Code plugin writes memories but recall/search returns empty — API key and OAuth both affected #792.

1 file changed, +9 / -1.

Test plan

• Typecheck: NODE_OPTIONS="--max-old-space-size=8192" tsc --noEmit from apps/mcp/ → zero new errors introduced on src/index.ts. Pre-existing errors in server.ts (SDK type duplication) and ui/mcp-app.ts (DOM types / @types/d3-force-3d missing) are unchanged by this PR.
• Manual: open an MCP session without forwarding x-sm-project, write a memory via the memory tool, then query /v3/search with containerTag: <userId> — the write should now be visible. Same memory should also be returned by MCP recall inside the session.
• Manual: open an MCP session with x-sm-project: my-project — behavior should be unchanged (writes and reads land in my-project).