Um.... ignore this for now. I can no longer reproduce it, and pullEnvRecords apparently does the right thing (initial analysis was wrong). I'm not sure if there was a server change that caused this or not. I've closed the issue and will monitor on our end.

vercel dev shouldn't be pulling anything automatically, if you want to get the latest env vars you need to use either vercel pull(which pulls into a .vercel directory)

Or I prefer using the more specific vercel env pull which only pulls my .env.local file

Were you using one of those when you ran into the issue?

Yes, I was using "vercel env pull" to bring the environment locally (after running a "vercel link"). Yet, we witnessed "vercel dev" pull 1.5MB of environment settings when it started, which included references to all open branches. It looks like when a project is linked, the environment is always pulled from Vercel, even if a local file is present.

What we are seeing today - "vercel dev" attempts to spawn subprocesses with a very large VERCEL_DEV_CONFIG (1.5MB), which the OS rejects with E2BIG. VERCEL_DEV_CONFIG contains configuration information for every single branch from our project, which is not required for running a local development server

Here's what I propose to change in the file commands/dev/dev.ts

1

2
@@ -145,7 +145,23 @@ export default async function dev(
3

4
     client.config.currentTeam = org.type === 'team' ? org.id : undefined;
5

6
-    projectSettings = project;
7
+    // The linked `project` response carries bulky runtime-only fields that are
8
+    // not part of `ProjectSettings` — notably `env`, an array of every
9
+    // environment record across all branches, and `latestDeployments`.
10
+    // `projectSettings` is serialized into `VERCEL_DEV_CONFIG` and injected into
11
+    // the forked dev server's environment; on projects with many branches that
12
+    // `env` array can push the environment block past the OS `ARG_MAX` limit and
13
+    // fail the fork with `E2BIG`. Keep only the settings — the real env values
14
+    // reach the dev server separately via `envValues`.
15
+    const {
16
+      env: _env,
17
+      latestDeployments: _latestDeployments,
18
+      ...settings
19
+    } = project as typeof project & {
20
+      env?: unknown;
21
+      latestDeployments?: unknown;
22
+    };
23
+    projectSettings = settings;
24
     projectId = project.id;
25
     orgId = org.id;

Thoughts? This certainly seems like a real bug. I've submitted a pull request with the fix above.

Hi Andrew, thank you so much for looking into this and submitting a fix! Really appreciate it.

Could you share a bit more on what the root cause was, and do you have any idea on the typical timeline for a fix like this to get merged and rolled out?

We've been dealing with this for a while and would love to know when we might expect it resolved.

This is my first contribution to the Vercel codebase, so I don't know what timeframes look like typically, sorry.

Root cause - not very sure on this one. We are pretty liberal with our use of branches, which is why we hit this.

Until this fix comes out, we are monkeypatching spawn in the node environment that "vercel dev" brings up, to remove the offending element in the environment.

Thanks buddy that proxying through Cloudflare worked as a workaround while his PR fix is pending, which could help others hitting the same issue