René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"child_process: default env ignores a reassigned process.env since v26.11.0","articleBody":"### Version\n\nv26.11.0 and later (tested v26.11.1, v26.12.0). v26.10.0, v24.14.1, and v22.23.3 are not affected.\n\n### Platform\n\n```text\nLinux x86_64 (official linux-x64 binaries)\n```\n\n### Subsystem\n\nchild_process\n\n### What steps will reproduce the bug?\n\n```js\n// repro.js\nconst { spawnSync } = require('node:child_process');\n\nprocess.env = { ...process.env, FOO: 'set' };\n\nconst args = ['-p', 'process.env.FOO'];\nspawnSync(process.execPath, args, { stdio: 'inherit' });                    // no options.env\nspawnSync(process.execPath, args, { stdio: 'inherit', env: process.env });  // explicit env\n```\n\n```console\n$ node-v26.10.0 repro.js\nset\nset\n\n$ node-v26.12.0 repro.js\nundefined\nset\n\n$ node-v26.12.0 --permission --allow-child-process --allow-fs-read='*' repro.js 2>/dev/null\nset\nset\n```\n\n### How often does it reproduce? Is there a required condition?\n\nAlways, when `process.env` has been reassigned and a child is spawned without `options.env` while the permission model is off. This affects every `child_process` API (`spawn`, `exec`, `execFile`, `fork`, and the sync variants).\n\nMutating `process.env` in place (`process.env.FOO = 'set'`) is not affected.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nA child spawned without `options.env` should get the same environment as one spawned with `{ env: process.env }`.\n\nThe `child_process` docs list the `env` default as `process.env` for every spawning API, and say \"Use `env` to specify environment variables that will be visible to the new process, the default is `process.env`\" ([L177](https://github.com/nodejs/node/blob/v26.12.0/doc/api/child_process.md?plain=1#L177), [L751](https://github.com/nodejs/node/blob/v26.12.0/doc/api/child_process.md?plain=1#L751)). Command lookup is documented as using `options.env.PATH`, falling back to `process.env.PATH` ([L55](https://github.com/nodejs/node/blob/v26.12.0/doc/api/child_process.md?plain=1#L55)).\n\n`process.env` is writable, and nothing deprecates or warns about reassigning it. `{ env: process.env }` still sees the reassigned object, so the actual default and the documented default now disagree.\n\n`Worker`, `TZ`, and `os.homedir()` read the OS environment, so reassigning `process.env` never affected them. `child_process` is different: its default is documented as `process.env`, and until v26.10.0 it was implemented by copying `process.env`.\n\n### What do you see instead?\n\nThe child gets the OS environment and ignores the reassigned `process.env`. `FOO` is unset, and a reassigned `PATH` is ignored for command lookup.\n\nThe result also depends on `--permission`. With the permission model on, the old code path runs and the child sees `FOO=set`.\n\n### Additional information\n\nCaused by #65325 (\"child_process: build the default env block in one native pass\", first released in v26.11.0). When `!options.env && !permission.isEnabled()`, `normalizeSpawnArguments()` builds `envPairs` with `getEnvPairs()`, which reads the OS environment block, instead of copying `process.env` ([lib/child_process.js L706](https://github.com/nodejs/node/blob/v26.12.0/lib/child_process.js#L706)). Its test (`test-child-process-default-env.js`) only mutates `process.env` in place and never reassigns it.\n\nReassigning `process.env` with a spread copy is a common pattern. [GitHub code search](https://github.com/search?q=%22process.env+%3D+%7B+...process.env%22&type=code) finds a few thousand files containing `process.env = { ...process.env`, for example in build scripts, test setup, and Vite configs. Tools that override `PATH` or `npm_config_*` this way and then spawn without `env` lose the overrides on v26.11+ without any error. We hit this with an npm wrapper that sets `NPM_CONFIG_REGISTRY` and `PATH` this way: its npm child fell back to registry.npmjs.org.\n\nPossible fixes:\n- keep the fast path, but only take it while `process.env` is still the native env proxy. For example, pass `process.env` to `getEnvPairs()` and fall back to the copy path unless `env_proxy_ctor_template()->HasInstance()` is true (the check `node_messaging.cc` already uses). Spreading a reassigned plain object is cheap, so the speedup is kept where it matters;\n- or revert #65325 on v26.x before v26 enters LTS on 2026-10-28. If the new behavior is intended, label it semver-major after the fact so it ships only in v27, and update the `options.env` default and the PATH lookup docs.\n","author":{"url":"https://github.com/everett1992","@type":"Person","name":"everett1992"},"datePublished":"2026-10-20T16:20:39Z","url":"https://github.com/nodejs/node/issues/66882"}