Debug and fix pi-task extension loading in pi-kobold (Node/Bun, pi agent)
Session from 0xKobolds on Hugging Face by moikapy · MIT · condensed by Coders Talk
Figure out how to test the pi-task Kanban extension as part of the pi-kobold meta-extension, and get it actually loading and working inside the pi coding agent.
- +0Prompt · +0We updated pi-kobold on the pi agent — how should we go about testing the pi-task extension that's part of it?
- +0mAgent did · +0mInvestigated pi-coding-agent internals and the 0xKobolds monorepo, found pi-task is a kanban SQLite extension bundled via pi-kobold, and traced why it wasn't loading: pi-kobold's package.json used file:../pi-task and file:../pi-web references that don't resolve when installed from npm.
- +18mAgent did · +18mFixed pi-kobold's dependency references to pin pi-task/pi-web by npm version instead of file: paths, rebuilt, bumped and published pi-kobold 0.7.4, then discovered pi-task itself crashed on load because it used bun:sqlite which doesn't exist under Node — rewrote store.ts to use sql.js (WASM SQLite) following pi-learn's pattern.
- Break · 6h 40m away, not counted
- +44mIntervention · +44mDeveloper paused to ask why the agent switched pi-task from bun:sqlite to sql.js before letting it continue.Why: I wanted to understand the reasoning before letting it keep publishing changes — needed to confirm it wasn't just working around a symptom.
- +51mFail · +51mEnd-to-end test of the rebuilt pi-task crashed inside sql.js's WASM loader, later traced to a race in ID generation (Date.now() collisions for history/comment IDs) and to the global npm install still serving the old dist.
- +51mAgent did · +51mFixed the ID collision with a counter+random suffix, rebuilt, republished pi-task 0.2.1 and pi-kobold 0.7.6, reinstalled globally, and confirmed via direct Node test and pi pkg list that pi-task now loads and all CRUD operations pass.
- +1h 0mPrompt · +1h 0mOn another machine, pi-kobold fails to load: pi-task throws a require error and pi-web's web_fetch/web_search tools conflict with @ollama/pi-web-search — how do I fix both and keep both extensions?
- +1h 1mAgent did · +1h 1mAdded explicit WASM binary path resolution to pi-task's sql.js init to fix the require/load crash, renamed pi-web's tools to pi_web_fetch/pi_web_search/pi_web_research to remove the naming collision, republished pi-web 0.2.0, pi-task 0.2.2 and pi-kobold 0.7.7, then verified globally with pi pkg list and a full Node test of the store.
- +1h 9mOutcome · +1h 9mpi-task and pi-web both load cleanly with zero errors; pi-kobold published at 0.7.7 with pi-task 0.2.2 and pi-web 0.2.0, all store operations (create/list/assign/comment/delete) pass in a direct test.
Next time I'd open by asking the agent to check the actual runtime (Node vs Bun) and how extensions get resolved from npm before assuming the file: dependencies would just work — that mismatch cost most of the session. The one correction that mattered was stopping to ask why it swapped bun:sqlite for sql.js, which forced it to explain the Node/Bun runtime issue clearly instead of just quietly patching around it. Publishing repeatedly and re-testing against the real global install (not just the local dist) is what actually surfaced the WASM path and tool-collision bugs on a second machine.