- .mcp.json: use ${MEM0_API_KEY} instead of ${user_config.MEM0_API_KEY}
so MCP connects for --plugin-dir users with the key in their shell
- mem0-onboard: check MCP tools availability first, stop early with
clear instructions if MCP server not connected
userConfig was missing required `type` and `title` fields per Claude Code
plugin docs — value was never collected, so ${user_config.MEM0_API_KEY}
could not resolve. Added both fields. Restored .mcp.json to use
${user_config.MEM0_API_KEY} for the MCP server Authorization header.
This completes the fix for #4876: plugin now prompts for API key at
install, stores in keychain, and MCP server reads it via user_config
interpolation — no shell env var needed.
${user_config.*} interpolation not supported in HTTP-type MCP server
headers — only works for subprocess-based servers. Revert to shell
env var reference. The userConfig + resolve_api_key() fallback chain
still fixes hook scripts for issue #4876.
Root cause: .mcp.json required ${MEM0_API_KEY} shell env var which
OAuth flow never populates — MCP server never started, only auth
stubs were exposed.
Fix: switch .mcp.json to ${user_config.MEM0_API_KEY} so Claude Code
reads the key from plugin userConfig (system keychain). Add
resolve_api_key() fallback chain (MEM0_API_KEY -> CLAUDE_PLUGIN_OPTION_MEM0_API_KEY)
to all hook scripts. Update onboard skill and setup_coding_categories.py
to handle keychain-only users. Add 3 tests for key resolution.