Summary
A fresh npm install -g @waishnav/devspace produces a broken pi subagent. Every devspace agents run pi ... fails immediately with:
TypeError: Cannot read properties of undefined (reading 'create')
Environment
Measured
src/local-agent-pi.ts imports AuthStorage and calls AuthStorage.create():
const { AuthStorage, ModelRegistry, SessionManager, DefaultResourceLoader, createAgentSession, getAgentDir } =
await import("@earendil-works/pi-coding-agent");
const agentDir = getAgentDir();
const authStorage = AuthStorage.create(join(agentDir, "auth.json"));
const modelRegistry = ModelRegistry.create(authStorage, join(agentDir, "models.json"));
A clean install resolves ^0.80.3 to 0.80.10:
$ npm install @waishnav/[email protected]
$ node -e "console.log(require('@earendil-works/pi-coding-agent/package.json').version)"
0.80.10
In 0.80.10 that export is gone:
$ grep -c AuthStorage node_modules/@earendil-works/pi-coding-agent/dist/index.d.ts
0
$ node --input-type=module -e "
const m = await import('@earendil-works/pi-coding-agent');
m.AuthStorage.create('/tmp/x.json');
"
TypeError: Cannot read properties of undefined (reading 'create')
Runtime result:
$ devspace agents run pi "reply with exactly: OK" --json
{"id":"agt_d11f5d84","status":"running"}
$ devspace agents show agt_d11f5d84 --json # after ~30s
{"id":"agt_d11f5d84","status":"failed","error":{"code":"AGENT_INTERNAL_ERROR","message":"Unexpected internal subagent failure.","retryable":false}}
And in devspace agents daemon logs:
{"event":"agent_run_failed","provider":"pi","agentId":"agt_d11f5d84","durationMs":2,"error":"Unexpected internal subagent failure.","errorType":"TypeError","persistenceFailed":false}
Why the lockfile hides it
pnpm-lock.yaml pins @earendil-works/pi-coding-agent to 0.80.3, which still exports AuthStorage:
0.80.3 index.d.ts AuthStorage occurrences: 1
0.80.10 index.d.ts AuthStorage occurrences: 0
CI installs with pnpm install --frozen-lockfile, so it builds and tests against 0.80.3. Anyone installing the published package without the lockfile gets 0.80.10 and a non-functional pi subagent.
Inferred cause
0.80.10 replaced the exported AuthStorage / ModelRegistry pair with ModelRuntime.create({ authPath, modelsPath }). local-agent-pi.ts still uses the removed API, and the PiSessionLike type still requires session.modelRegistry, which is also gone.
Notes
devspace agents run codex ... and devspace agents run opencode ... are unaffected by this; they fail or succeed for unrelated reasons on this machine.
- I could not confirm which pi release dropped the export; no changelog entry was obvious from the package contents.
Leaving the fix approach to you — either adjust the dependency range or move to ModelRuntime. I have a local workaround but did not want to assume which direction you prefer.
Summary
A fresh
npm install -g @waishnav/devspaceproduces a brokenpisubagent. Everydevspace agents run pi ...fails immediately with:Environment
pisubagent provider, added in the in-process Pi work (feat: embed Pi sessions in process #187 / perf(pi): run subagent sessions in-process #194)Measured
src/local-agent-pi.tsimportsAuthStorageand callsAuthStorage.create():A clean install resolves
^0.80.3to 0.80.10:In 0.80.10 that export is gone:
Runtime result:
And in
devspace agents daemon logs:{"event":"agent_run_failed","provider":"pi","agentId":"agt_d11f5d84","durationMs":2,"error":"Unexpected internal subagent failure.","errorType":"TypeError","persistenceFailed":false}Why the lockfile hides it
pnpm-lock.yamlpins@earendil-works/pi-coding-agentto 0.80.3, which still exportsAuthStorage:CI installs with
pnpm install --frozen-lockfile, so it builds and tests against 0.80.3. Anyone installing the published package without the lockfile gets 0.80.10 and a non-functionalpisubagent.Inferred cause
0.80.10 replaced the exported
AuthStorage/ModelRegistrypair withModelRuntime.create({ authPath, modelsPath }).local-agent-pi.tsstill uses the removed API, and thePiSessionLiketype still requiressession.modelRegistry, which is also gone.Notes
devspace agents run codex ...anddevspace agents run opencode ...are unaffected by this; they fail or succeed for unrelated reasons on this machine.Leaving the fix approach to you — either adjust the dependency range or move to
ModelRuntime. I have a local workaround but did not want to assume which direction you prefer.