Repository navigation
eve-on-Vercel: source deploy 500s (ERR_MODULE_NOT_FOUND for internal #channel/*), and --prebuilt skips sandbox prewarm — no clean deploy for sandbox apps #556
Description
Link to a minimal reproduction
I don't have a standalone minimal repro repo yet — this was found on a real (private) production deployment, and I can't easily reproduce a fresh Vercel build outside that project right now. I'm filing anyway because the evidence points directly at eve's own source (see below), and I'm very happy to build and link a minimal repro (a tiny eve app with one sandbox-using subagent) if that helps you triage.
Steps to reproduce
- An eve app with at least one node/subagent that uses a sandbox (so eve provisions a Vercel Sandbox template).
- Deploy it to Vercel with a source
vercel deploy(Vercel builds from source — the path eve's own warning recommends). - Open any route of the resulting deployment (
/,/eve/v1/slack, …).
Current vs. expected behavior
Current: every route returns HTTP 500 FUNCTION_INVOCATION_FAILED. The runtime logs show ERR_MODULE_NOT_FOUND for an eve-internal #channel/* import (e.g. #channel/compiled-channel). The generated Vercel function's dependency trace appears to drop eve's internal #… subpath files, so they're missing at runtime.
Expected: a source vercel deploy serves the routes normally (the internal #channel/* modules are included in the traced function bundle).
Why this matters (the bind): the two deploy paths are mutually exclusive and both break sandbox apps:
- Source deploy (
vercel deploy): eve does provision the Vercel Sandbox templates (the on-Vercel build runs prewarm, gated onVERCEL_DEPLOYMENT_ID) — build log showseve: initialized N sandbox templates— but every route 500s from the trace gap above. - Prebuilt deploy (local
vercel build+vercel deploy --prebuilt, with the traced output hand-patched to re-add the dropped#channel/*files): routes work, but the sandbox templates were never provisioned (a local build has noVERCEL_DEPLOYMENT_ID, so prewarm is skipped) → any agent that touches a sandbox throwsSandboxTemplateNotProvisionedErrorat runtime.
So there's no single-command deploy for an eve app that uses sandboxes on Vercel. eve's own build even warns about the sandbox half:
Skipped Vercel sandbox template prewarm because
VERCEL_DEPLOYMENT_IDis missing. The generated.vercel/outputmay reference sandbox templates that were not provisioned. Do not deploy it withvercel deploy --prebuilt; usevercel deployso Vercel builds from source.
…but "use vercel deploy" is exactly the path that 500s from the trace gap.
eve version
0.19.0
Environment
- Node.js 24 (both the local build and the on-Vercel build).
- Vercel (Fluid Compute), deployed via the Vercel CLI.
- Build via
vercel build/vercel deploywithVERCEL_USE_EXPERIMENTAL_FRAMEWORKS=1.
Where does the bug occur?
At deploy/runtime on Vercel (a source vercel deploy's deployment). The build succeeds; the failure is at request time.
Deployment
A private production deployment (can share the deployment ID privately with the team to correlate platform-side logs).
Build and runtime logs
- On-Vercel build (provisioning works):
eve: initializing 6 sandbox templates …/eve: sandbox template "subagents/<id>" (vercel): preparing base runtime inside sandbox/eve: initialized 6 sandbox templates (0 reused, 6 built). - Source-deploy runtime:
HTTP 500 FUNCTION_INVOCATION_FAILEDon/and/eve/v1/slack, withERR_MODULE_NOT_FOUNDfor an eve#channel/compiled-channelimport. - Relevant eve source: the prewarm gate is
dist/src/internal/nitro/host/vercel-build-prewarm.js→shouldPrewarmVercelBuild()(requires bothVERCELandVERCEL_DEPLOYMENT_ID).
Suggested direction
If eve's package exports (and/or the nitro tracing it emits) followed the internal #channel/* subpaths, a plain source vercel deploy would serve correctly and provision sandboxes in one step — removing the community --prebuilt + trace-patch workaround entirely. Happy to help test a fix or provide a minimal repro.
Activity
feat(cli): deploy provisions coding/channel sandbox templates before …
ruiconti commentedon Oct 14, 2026
Closing as stale. This was reported on 0.18; the deploy and attachment provisioning paths involved have since been replaced (#3263, #4635), and it hasn't been reproduced on a current release.
If this still happens on the current release (eve@0.79.1), please reopen with a reproduction.