Cursor’s shell integration (cursor-shell) automatically sets NODE_ENV=production in terminal sessions. This breaks standard Node.js development workflows, particularly:
Next.js dev server (attempts to run production build, fails when .next folder is missing)
Create React App and other build tools that rely on NODE_ENV being unset or development
Root Cause
The process hierarchy shows cursor-shell sits between iTerm and the user’s shell:
iTerm → cursor-shell → /bin/zsh
Because the injection happens above the shell level, the NODE_ENV variable:
Persists even after restarting the shell
Cannot be cleared with unset NODE_ENV (immediately returns)
Only disappears when opening new terminal windows after disabling Cursor’s shell integration
Debugging Challenge
This issue is extremely difficult to diagnose because:
No configuration files show this setting
The variable isn’t set in any shell initialization files
Standard debugging approaches (new shell sessions, env -i tests) don’t reveal the problem
The injection is completely transparent to the user
Resolution
After uninstalling cursor-agent shell integration (and possibly Cursor IDE shell integration) and opening new terminal windows (not just new shells), NODE_ENV was finally unset.
Request
Please reconsider this design. Setting NODE_ENV=production by default in development tools is counterintuitive and breaks standard workflows. If this is intended as a safety measure, it should be:
Optional and configurable
Clearly documented
Visible to users (not silently injected)
At minimum, development tools should default to NODE_ENV=development or leave it unset, allowing developers to set it explicitly when needed.
Same issue here. My development workflow broke following Cursor update as NODE_ENV=production caused issues like npm i not installing dev deps (and more).
This looks like a bug - or at least a breaking change that should be advertised.