fix(dsbx): resolve drizzle-kit at its image install path

[smb2268]

Description

dsbx db schema (the get-DB-schema MCP path) fails with drizzle-kit not found on PATH, while the binary is visibly present in an interactive sandbox shell.

Root cause: non-root sandbox.exec commands run in a --noprofile --norc shell with PATH pinned to /usr/sbin:/usr/bin:/sbin:/bin:/opt/bin (sandbox service-account hardening). /opt/bin/dsbx resolves, but the runner then looked up drizzle-kit via Bun.which against that inherited PATH — and the image's global npm install lives at /opt/npm-global/bin, which the pinned PATH deliberately excludes. Interactive shells source the profile and see the full PATH, which is why shell-based debugging shows the binary "on PATH".

Fix: resolve drizzle-kit by explicit path only, never through the caller's PATH — the image install (/opt/npm-global/bin/drizzle-kit, root-owned npm install -g at image build) first, the package-local node_modules/.bin (devDependency) as the dev/test fallback. The failure message names both candidates. The bun-shebang-bypass invocation is unchanged.

Deliberately not done: widening the hardened PATHs. Note the exec runs as the agent service user (execOpts?.user ?? "agent"), whose safe PATH is the same constant as root's — a PATH-based fix would widen root's exec PATH or require splitting that alias plus standing ownership guarantees on /opt/npm-global, for what an audit shows is a single-caller problem (every other binary dsbx spawns — bun, runuser, nft — lives in /opt/bin or /usr/sbin, already on the pinned PATHs).

Risk

Worst case, drizzle-kit resolution fails with an error naming both checked paths — same failure mode as today, better message. No hardening/PATH changes. Safe to rollback.

Tests

Resolver unit tests (image install wins / local fallback / neither → error naming both paths); existing db suite green (48 tests).

Deploy Plan

Mirrors the image-rollout process from Harden sandbox uid 1002 service boundary (#29411) — this fix rides inside the dsbx binary embedded in the sandbox image, so a front deploy alone does not reach sandboxes, and sleeping sandboxes retain their original image.

1. Cut a dsbx release with this fix and build the next dust-base image embedding it; confirm the validated templates are available in both E2B regions (the deploy workflow gates front on image availability).
2. Deploy front pinned to the new dust-base version — new sandboxes pick up the patched dsbx.
3. Kill sandboxes on older dust-base versions via /poke/kill — sleeping sandboxes retain their original image, so without this, existing Computers (including the pod this was reported on) wake up with the old dsbx and keep the bug. At minimum, kill the affected pods' sandboxes; a full sweep matches the Harden sandbox uid 1002 service boundary #29411 process.
4. Verify no non-deleted sandbox remains on an older version, then re-run the get-DB-schema MCP on the reporting pod — covering both a fresh Computer and a woken one.

Note

Validated ahead of rollout: the patched dsbx was hot-swapped into a live sandbox via upsert_dsbx_to_sandbox.sh and the get-DB-schema flow succeeds under the hardened exec PATH.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
playground	Ignored	Preview	Aug 7, 2026 8:01pm
storybook	Ignored	Preview	Aug 7, 2026 8:01pm

[dust-agent]

Coding Rules LGTM \o/

[fontanierh]

LGTM 🙏 Thanks for fixing!

You need to bump the version tags for both DSBX and the sandbox image.
Then, lock front, release dsbx CLI, run the sandbox registry workflow, and deploy front.