@yawlabs/mcph 0.47.1 → 0.47.3

package/CHANGELOG.md

@@ -2,6 +2,10 @@
 
 All notable changes to `@yawlabs/mcph` are documented here. This project uses [semantic versioning](https://semver.org) and a CI-gated release flow: pushing a `vX.Y.Z` tag triggers `.github/workflows/release.yml`, which publishes to npm.
 
+## 0.47.2 — 2026-05-01
+
+- **`mcph install claude-code` honors `CLAUDE_CONFIG_DIR`** — When Claude Code runs under a wrapper that sets `CLAUDE_CONFIG_DIR` (Yaw Mode's per-session overlay, dev containers that pin a config dir, sandboxed sessions), the user-scope MCP file moves from `~/.claude.json` to `<DIR>/.claude.json`, and `settings.json` moves from `~/.claude/settings.json` to `<DIR>/settings.json` (the `.claude` segment is absorbed by the env redirect — the dir IS the `.claude` equivalent). Prior versions of `mcph install` always wrote to the HOME-based defaults, so a user inside a wrapped session would get a "successful" install whose entry landed in a file Claude Code wasn't reading — `claude mcp list` then showed nothing despite the install reporting success. Discovered when a Yaw Mode session reported `claude mcp list` as empty after `npx -y @yawlabs/mcph install claude-code --token ...` returned 0 and the entry was visibly present in `~/.claude.json`. The CLI dispatcher in `index.ts` now reads `process.env.CLAUDE_CONFIG_DIR` once and passes it through `runInstall` → `resolveInstallPath` / `resolveClaudeCodeSettingsPath`. The same env is plumbed through `runDoctor` → `probeClients(Async)` so `mcph doctor` and `mcph install --list` see the same file Claude Code reads in this session. Resolver functions stay pure (no `process.env` reads inside) — env-handling lives in the entry points so unit tests stay deterministic regardless of whether the test runner inherits a real `CLAUDE_CONFIG_DIR`. Project-scope (`<project>/.mcp.json`) and project/local-scope `settings.json` (project-relative) are unaffected. Cursor / Claude Desktop / VS Code paths are unaffected (Claude Code is the only client that reads `CLAUDE_CONFIG_DIR`). 17 new tests lock the redirect for resolver, install, and doctor.
+
 ## 0.47.1 — 2026-04-18
 
 - **README intro rewritten to frame mcph's value vs. `claude mcp add` / hand-edited `mcp.json`** — Same forum thread (r/cursor, 2026-04-18) had a second comment that v0.47.0 didn't address: "I don't think any developer is 9$ a month afraid of json. Also all of those tools have a nicer way of installing mcp servers than editing json." Fair — the old intro led with "never hand-edit MCP JSON configs again," which is exactly the dismissal that lands. The new intro replaces that line with four concrete situations where mcph earns its keep (multi-client / multi-machine sync, `dispatch` context-pruning for large server accounts, encrypted credential centralization, A–F compliance visibility). It then *concedes* the skeptic's point directly in the last sentence: "If you use one client on one machine with a handful of servers, `claude mcp add` or hand-editing `mcp.json` is fine — mcph's value shows up when that setup stops scaling." Honest framing beats defensive framing; the people who actually have the scaling problem will self-select in.

package/README.md

@@ -302,10 +302,6 @@ When both exist, the project guide is appended after the user guide with a `---`
 
 When a server fails to start with stderr like `GITHUB_TOKEN is required` and your client advertises the MCP [elicitation](https://modelcontextprotocol.io/specification/server/elicitation) capability, mcph prompts you for the missing value inline and retries the load. Values stay in-memory for the current mcph session only — persist them in the mcp.hosting dashboard if you want them across restarts.
 
-### Test from the dashboard
-
-The `/dashboard/connect` page in mcp.hosting has a **Test** button per server that loads it through your running mcph and shows pass/fail inline — no LLM round-trip needed. Useful when you've just added a server and want to confirm the token works without prompting your AI.
-
 ### Errors come with deep-links
 
 When a load fails (missing token, runtime not on PATH, server crashes on init), mcph emits a message ending with `→ Edit at https://mcp.hosting/dashboard/connect#server-<id>`. Most LLMs render that as a clickable link, and the dashboard scrolls to and highlights the matching card so you find the right server in one click.
@@ -345,7 +341,7 @@ The detection is best-effort: each probe has a 3-second timeout and missing runt
 
 ### Automatic `uv` bootstrap
 
-The popular Python-based MCP servers (`fetch`, `sqlite`, `time`, `sentry`, etc.) all launch via Astral's `uv`/`uvx`. mcph ships its own bootstrap for these: on first encounter with a `uv`/`uvx` command, if the binary isn't on your PATH, mcph lazily downloads Astral's standalone `uv` release, verifies the sha256, and caches it under the platform-appropriate cache dir. Subsequent loads reuse the cached binary. If you already have `uv` installed, mcph uses your version and never downloads.
+The popular Python-based MCP servers (`sqlite`, `time`, `sentry`, and other uvx-launched entries) all launch via Astral's `uv`/`uvx`. mcph ships its own bootstrap for these: on first encounter with a `uv`/`uvx` command, if the binary isn't on your PATH, mcph lazily downloads Astral's standalone `uv` release, verifies the sha256, and caches it under the platform-appropriate cache dir. Subsequent loads reuse the cached binary. If you already have `uv` installed, mcph uses your version and never downloads.
 
 `uvx ARGS` is always rewritten to `uv tool run ARGS` at spawn time — so only `uv` needs to be reachable, not `uvx` separately. Fixes Windows setups where one was on PATH and the other wasn't.