#204 · pantry-pm/pantry

Symptom

Pantry's shell integration (the shellcode that gets sourced into your interactive shell) does the wrong thing in package-management hooks — at minimum it runs bun install where it should be pantry install. Per Chris's 2026-05-07 6:37 AM task drop:

"please improve the pantry shellcode integration rn because it does some bad stuff, like, if i see it correctly, it runs bun install but thats obv wrong bc we'd want to pantry install - please test it some thoroughly again in projects like easyotc, etc. -> use it as your daily driver on your machine"

Why this matters

Pantry is the canonical package manager for our ecosystem (per memory: ts-cloud, etc. use Pantry, not bun). When the shell integration shells out to bun install it bypasses pantry entirely — wrong cache, wrong resolver, wrong lockfile. Anyone whose shell sources our shellcode and runs cd into a project will silently get the wrong installer behavior.

Acceptance

Audit every bun install (and any other hardcoded package-manager invocation) in the shell integration. Replace with pantry install where appropriate, or with a router that picks the right tool based on the project (pantry vs bun-only-monorepo vs npm-legacy).
Validate with daily-driver use: install pantry's shell integration, use it as the active shell for >1 day, work in real projects (easy-otc, ts-cloud, training, pet-store) — surface and fix any other wrong-tool invocations.
Document the routing rules: when does the integration call pantry install, when does it call something else, and why.

Reproducer

Source pantry's shell integration in zsh / bash.
cd into any project with a pantry.lock (e.g. ts-cloud).
Trigger whatever hook auto-runs the installer (or run the documented command).
Observe bun install running instead of pantry install.

Notes

This is the kind of bug that only surfaces under daily use — unit tests on the shellcode won't catch it. The "use it as daily driver" step is part of the fix, not a nice-to-have.