Repository navigation
expect-cli crashes on launch: ERR_UNSUPPORTED_DIR_IMPORT (ink → es-toolkit/compat) #104
Description
Expect MCP Server — Connection Failure Context
Summary
The expect MCP server is configured and approved in this repo, but it does not connect because the upstream expect-cli package crashes on launch under Node.js with an ERR_UNSUPPORTED_DIR_IMPORT error originating from ink → es-toolkit/compat.
Repository
- Path:
/home/user/untab - Branch:
claude/test-expect-mcp-connection-HA1mw
Configuration (correct, no changes needed)
.mcp.json:
{
"mcpServers": {
"expect": {
"command": "npx",
"args": ["-y", "expect-cli@latest", "mcp"]
}
}
}.claude/settings.json:
{
"enabledMcpjsonServers": ["expect"],
"enabledPlugins": {
"chrome-devtools-mcp@chrome-devtools-plugins": true
},
"extraKnownMarketplaces": {
"chrome-devtools-plugins": {
"source": {
"source": "git",
"url": "https://github.com/ChromeDevTools/chrome-devtools-mcp.git"
},
"autoUpdate": true
}
}
}The server is declared and explicitly enabled. The Claude Code session lists no mcp__expect__* tools, confirming the server failed to start.
Reproduction
npx -y expect-cli@latest --versionSame failure with both:
- Node.js v22.22.2 (system)
- Node.js v24.15.0 (Vite+ runtime via
vp env print→/root/.vite-plus/js_runtime/node/24.15.0/bin)
Error
Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import
'/root/.npm/_npx/015c9764bdd64143/node_modules/es-toolkit/compat'
is not supported resolving ES modules imported from
/root/.npm/_npx/015c9764bdd64143/node_modules/ink/build/ink.js
Did you mean to import "es-toolkit/compat.js"?
at finalizeResolution (node:internal/modules/esm/resolve:259:11)
at moduleResolve (node:internal/modules/esm/resolve:861:10)
at defaultResolve (node:internal/modules/esm/resolve:988:11)
...
code: 'ERR_UNSUPPORTED_DIR_IMPORT',
url: 'file:///.../node_modules/es-toolkit/compat'
Root Cause Hypothesis
ink (transitive dependency of expect-cli) imports from 'es-toolkit/compat' — a bare directory specifier. Node's strict ESM resolver rejects this unless the target package's exports map declares the subpath, or the import points at a real file (es-toolkit/compat.js). The version of es-toolkit that gets hoisted in the npx resolution does not expose ./compat as a subpath, so resolution fails before any CLI code runs.
Upstream
- npm package:
expect-cli - Repository: https://github.com/millionco/expect (subdirectory:
apps/cli) - Issues: https://github.com/millionco/expect/issues
- Homepage: https://expect.dev
- Maintainer: Million Software
<[founders@million.dev](mailto:founders@million.dev)>
Possible Fixes (any of)
- Pin
inkinexpect-clito a version whosees-toolkitimport targets a file path (es-toolkit/compat.js), or one that uses a subpath supported by thees-toolkitexportsmap. - Pin
es-toolkit(viaexpect-cli's lockfile/overrides) to a version that exposes./compatas a directory subpath inexports. - Add an
overrides/resolutionsblock toexpect-cli'spackage.jsonso the transitive resolution stays aligned with whatinkexpects. - As a temporary workaround for users: pin to a known-good earlier
expect-cliversion in.mcp.json:"args": ["-y", "expect-cli@<known-good-version>", "mcp"]
Impact
expect-cliis unusable as a CLI (--version,--help, etc. all fail at module resolution).- The
expectMCP server cannot start, so Claude Code sessions in this repo have nomcp__expect__*tools available. - Affects both Node 22 and Node 24, so a Node downgrade is not a viable workaround.
Suggested Next Steps
- File the upstream issue at https://github.com/millionco/expect/issues using the body in this document.
- While waiting on a fix, optionally pin
expect-clito the latest known-working version in.mcp.jsonand re-approve the server. - Re-run a Claude Code session and confirm
mcp__expect__*tools appear.
Activity
hckhanh commentedon Apr 28, 2026
Scope clarification: I believes this only reproduces inside the Claude Cloud / cloud-sandbox environment where Claude Code agents run — a restricted Linux container. Two details in the original report are consistent with that:
npxwrites its cache to/root/.npm/_npx/...(root user inside a container), and the Vite+ runtime path is/root/.vite-plus/.... On a normal local workstation install the failure may not appear, presumably becausenpm/npxhoists a differentes-toolkitversion that does expose./compatas a directory subpath in itsexportsmap.This doesn't change the fix recommendations — pinning
ink/es-toolkitviaoverrides(or upgradinginkto a version that imports'es-toolkit/compat.js'instead of the bare directory) would make the package robust against either resolution outcome. But it does explain why a local reproduction attempt may not surface the error.