[BUG]: vite dev returns 500 on SvelteKit 3 + adapter-cloudflare 8: "no __VARLOCK_ENV binding found" #1267

varlock version

• varlock 1.24.0
• @varlock/vite-integration 1.5.5
• @varlock/cloudflare-integration 1.6.3
• @sveltejs/kit 3.1.1, @sveltejs/adapter-cloudflare 8.0.2, wrangler 4.151.3

Steps to reproduce

1. SvelteKit 3 app with adapter-cloudflare configured inline in vite.config.js, and varlockVitePlugin() before sveltekit(), as in the SvelteKit guide.
2. Run vite dev.
3. Request any SSR page.

What is expected?

The page renders, with varlock's env loaded through its normal dev flow ("vite dev runs SvelteKit's dev server; varlock resolves env via its normal flow").

What is actually happening?

Every SSR request returns 500:

Internal server error: [varlock] no __VARLOCK_ENV binding found on this Worker. Varlock injects it in `vite dev` and `vite preview`; for the built output, run and deploy through varlock's wrappers rather than the Cloudflare CLI directly. See https://varlock.dev/integrations/cloudflare/

Two recent changes combine to cause this:

• Since Detect the Cloudflare adapter with SvelteKit 3 #1240, the Workers env loader (CLOUDFLARE_SSR_ENTRY_CODE) is injected on SvelteKit 3, in dev as well as in builds.
• adapter-cloudflare 8 emulates cloudflare:workers in dev: the import resolves in Node to wrangler's platform proxy env. The loader's comment and the SvelteKit guide both assume that import fails outside Workers.

So in dev, __cfEnv is the proxy's env, which has no __VARLOCK_ENV binding, and the check added in #1236 throws. With @varlock/cloudflare-integration 1.6.2 (no throw), the loader falls through, varlock loads the env normally, and dev works.

System Info

macOS 27.2, Node 24.22.1, pnpm 11.25.0

Any additional comments?

We pinned @varlock/cloudflare-integration to 1.6.2 for now. Two fixes that would work from our side: skip the throw when the vite plugin is running vite dev, or add __VARLOCK_ENV to the dev env the way varlockCloudflareVitePlugin does through wrapWorkerConfig. In a local workaround we set platform.env.__VARLOCK_ENV = process.env.__VARLOCK_ENV on the adapter's platform proxy, and that fixed it too.