Repository navigation
Use case: WebDev BLOCKED -- shell invocations have NODE_ENV environment variable automatically set to production #151
Description
Describe the bug
Open up copilot on Windows. Tell it to run dir Env:. What you'll see is the NODE_ENV environment variable set to production.
Automatically setting this means that jest tests behave differently when run in the copilot cli compared with regular invocations.
Affected version
0.0.330 Commit: a8bfefe
Activity
dsmaher commentedon Oct 11, 2025
This is also the case running in WSL so I suspect this is not unique to Windows. This took a while for me to figure out why when copilot was working on a node.js project it had a very different experience from when I was working on it outside of copilot. The project would not install any
devDependencieswhen copilot rannpm install(which makes sense, once I figured out the cause). I now add a**CRITICAL**hint to Copilot in my prompts to "ALWAYS unsetNODE_ENVwhen runningnpmcommands".Tiberriver256 commentedon Oct 11, 2025
@RyanHecht possible to raise the priority of this fix now that it's not just a Windows issue? Would really like to start using this tool for things that use node (webdev, etc.) and this makes it really difficult.
mrairdon-midmark commentedon Oct 15, 2025
Just wanted to post here to say this is still an issue even with the latest updates.
Also, to give some clarity on the context of this problem. It is a blocker for being able to use this tool for web development. Most testing libraries in the web dev ecosystem key off of that environment variable.
[-]PowerShell invocations have NODE_ENV environment variable automatically set to `production`[/-][+]Use case: WebDev BLOCKED -- PowerShell invocations have NODE_ENV environment variable automatically set to `production`[/+]dsmaher commentedon Oct 15, 2025
@mrairdon-midmark I've been able to work around this problem by including the following in my prompts or in
copilot-instructions.md:Phrasing it this way prioritizes this instruction to the LLM and it remembers it throughout the session when it runs tools, and can avoid the issues that arise from the current buggy behavior. Obviously you can update the phrasing so it sets
NODE_ENVto whatever value you want and is used for any other commands you need it to handle.It's clearly not the right solution, but it at least unblocks my use cases. Hopefully this option can help you, too.
mrairdon-midmark commentedon Oct 15, 2025
Thanks @dsmaher! That did help for me personally, but ultimately blocks me from recommending it widely within my org. Coordinating that bit across 40-50 devs will be a fun time, haha. I'd rather wait until it just works out of the box.
uyrabi commentedon Oct 20, 2025
This also happens on Mac.
When using a tool called vibe kanban, an error would sometimes occur only when AI was coding, but not when I did it manually.
Upon investigation, I found that the NODE_ENV variable was being rewritten, which changed the behavior of the web framework (in my case, React Router v7).
When I had the copilot cli output the value of NODE_ENV, it returned production.
Tiberriver256 commentedon Oct 23, 2025
@andyfeller @RyanHecht
Could we maybe get an update on this issue? Is out of the box support for web dev/node-based dev planned on the roadmap?
docs: add critical note about unsetting NODE_ENV for project setup
[-]Use case: WebDev BLOCKED -- PowerShell invocations have NODE_ENV environment variable automatically set to `production`[/-][+]Use case: WebDev BLOCKED -- shell invocations have NODE_ENV environment variable automatically set to `production`[/+]devm33 commentedon Nov 9, 2025
This is fixed in the latest prerelease 0.0.355-33