Hey, thanks for the report. It’s frustrating that this popped up again.
Help me narrow down where the variable is coming from. Next time you can reproduce it:
In the same agent session, ask the agent to run: echo "ELECTRON_RUN_AS_NODE=$ELECTRON_RUN_AS_NODE"
Open a regular terminal in Cursor via Terminal > New Terminal and run the same command there.
Note whether the agent command ran in the sandbox or not. You can see it in the chat on the command block when it runs in the sandbox.
Fully quit Cursor and reopen it from Finder or Dock, not via cursor from a terminal, then repeat steps 1 and 2.
Reply with what each step printed, plus how Cursor was launched in that session, Dock, the cursor command from a terminal, or right after an auto update. This will show which path is setting the variable.
For now, the workaround is to add unset ELECTRON_RUN_AS_NODE at the top of ~/.zshrc so Cypress works, or prefix the command with: env -u ELECTRON_RUN_AS_NODE npx cypress run
Thanks, that really narrows it down. If the variable isn’t present in the integrated terminal and only shows up in the agent commands and stays until you start a new chat, then it’s clearly coming from the agent shell environment, not from how the app is launched.
One thing that’ll help us finish this off. You’re running the agent without sandbox globally. If you temporarily enable sandbox for a single command, does ELECTRON_RUN_AS_NODE still leak through, or does it disappear? That’ll tell us if this is tied to the unsandboxed path.
For now, the workaround stays the same, either unset ELECTRON_RUN_AS_NODE at the start of ~/.zshrc, or use a prefix like:
env -u ELECTRON_RUN_AS_NODE npx cypress run
I’ve passed this to the team. I’ll reply here when there’s an update.
Hey Antoine! Sorry about this! I’ve currently opted you out of a change that I believe caused this issue. Can you restart Cursor and let me know if this still happens?
We were rolling out changes to our client side infrastructure that touched agent shell spawn which caused the regression. The changes are behind a feature gate that we were able to roll back. Restarting your client should fix the issue by picking up the updated gate state. Please let me know if it doesn’t!