claude-code - 💡(How to fix) Fix Desktop MCP extensions (DXT) aren't path-rewritten on SSH sessions like plugins are

Summary

When connecting via SSH to a remote machine with a different home directory, Claude Desktop correctly rewrites plugin paths but passes raw local paths for DXT-style MCP extensions to the remote. The remote Node process can't resolve them.

Environment

• Local machine: macOS, one username
• Remote machine (via SSH): macOS, different username (different home directory)
• The PDF MCP extension installed via the Desktop app's Extensions UI at ~/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.anthropic.pdf-server-mcp/

Observed in logs

[CCD] SSH: rewrote 7/7 plugin path(s) to remote-synced dirs

Plugins are handled correctly — they're synced to ~/.claude/remote/plugins/... on the remote and paths are rewritten before being passed to ccd-cli.

Spawning: node /Users/<local-user>/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.anthropic.pdf-server-mcp/dist/index.js
Error: Cannot find module '/Users/<local-user>/Library/Application Support/Claude/Claude Extensions/...'

DXT-style extension paths are not rewritten. The remote Node process tries to load the local path (/Users/<local-user>/...), which doesn't exist on the remote (/Users/<remote-user>/...), and fails with MODULE_NOT_FOUND.

Expected behavior

One of:

1. Extensions get the same sync + path-rewrite treatment as plugins. Sync the extension's dist/ to the remote (analogous to the remote-synced plugin dir) and rewrite the path before spawning.
2. Desktop skips spawning Claude Extensions on SSH sessions and logs a single informational line instead of a MODULE_NOT_FOUND per session.

Either is better than the current behavior (spawn + crash).

Impact

Low functional impact — the MCP tool is unavailable on SSH sessions, but the session still works for everything else. Noisy in logs: one failure per session start per affected extension.

Why this looks like a scope gap, not a design choice

The logs show that the SSH path-rewriting logic is already present and working for the plugins namespace. Extending it to DXT-style extensions (or making those extensions opt in/out of SSH handoff explicitly) seems like a localized fix rather than a broader refactor.

Workarounds

1. Disable the PDF MCP extension for SSH sessions in the app settings (cleanest — stops the log spam).
2. Manually install the PDF MCP server on the remote machine and configure it in ~/.claude/mcp.json there with an absolute path to the remote Node install. More setup but functional.

Related

• #47977 (closed as duplicate) — structurally similar (DXT ${__dirname} resolves to MSIX-virtualized path on Windows; child processes can't resolve it). Different OS + mechanism, but the same class of bug: Claude Desktop and the spawned child process disagree on where the extension's files live.