Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
I asked Cursor to summarize the issue based on our troubleshooting session:
Cursor’s remote server bootstrap pollutes the environment of every integrated terminal and every Agent shell tool with ARCH= (e.g. ARCH=x86_64). VSCode Remote‑SSH on the same machine, against the same container, does not exhibit this — the env is clean.
The leak comes from ~/.cursor-server/bin//bin/helpers/check-requirements.sh, which contains:
ARCH=$(uname -m)
(no local, no subshell). When the bootstrap sources this script instead of executing it as a subprocess, the assignment leaks into the parent shell, then into the cursor-server process, and from there into every shell it spawns. VSCode ships the same upstream Microsoft script but apparently runs it as a subprocess, so the leak never happens.
This breaks projects that use ARCH as a meaningful build/cross‑compile selector. In my case (Yocto SDK / cargo cross‑compile project), ARCH is supposed to be one of qemux86-64 | sm6-snowfish-nrt | sm7-marlin, and the project’s profile.d script gracefully defaults it when unset. The leaked ARCH=x86_64 triggers a WARNING: Unknown ARCH=x86_64. You can experience problems with rust. and silently skips CARGO_BUILD_TARGET / CARGO_TARGET_*_LINKER setup.
Steps to Reproduce
Set up any container/remote where the launching env intentionally sets ARCH to something other than the host arch (e.g. docker run --env ARCH=qemux86-64 …).
Connect with Cursor.
In a Cursor integrated terminal (or Agent shell), run echo $ARCH — it prints the host’s uname -m, not the value the container was started with.
Repeat with VSCode Remote‑SSH against the same container — it prints the value the container was started with.
Verifiable from /proc:
tr ‘\0’ ‘\n’ < /proc/1/environ | grep ^ARCH= → ARCH=qemux86-64 (correct)
tr ‘\0’ ‘\n’ < /proc//environ | grep ^ARCH= → ARCH=x86_64 (leaked)
Expected Behavior
The remote bootstrap should not modify ARCH (or any other unrelated env var) in the cursor-server process. The user’s terminal/agent shells should see exactly the env that container PID 1 was started with.
Suggested one‑liner fixes on Cursor’s side, in priority order:
Run check-requirements.sh as a subprocess instead of sourcing it (matches VSCode behavior).
Or, in check-requirements.sh, wrap the body in a subshell ( … ) or replace ARCH=$(uname -m) with a non‑leaking pattern (e.g. _arch=$(uname -m), then use $_arch).
Or, unset ARCH at the end of the script.
Operating System
Linux
Version Information
Version: 3.3.27
VSCode Version: 1.105.1
Commit: 80b138a7a0a948e1a798e9ed7867d76a1ba9a310
Date: 2026-05-08T02:26:22.498Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 41.5.0
Chromium: 146.0.7680.216
Node.js: 24.15.0
V8: 14.6.202.34-electron.0
OS: Linux x64 7.0.3-arch1-2
For AI issues: which model did you use?
Opus 4.7
Additional Information
It would also be nice if the remote bootstrap honored ~/.cursor-server/server-env-setup the way VSCode honors ~/.vscode-server/server-env-setup. That’s the documented escape hatch users reach for first when they hit env leaks like this, and currently it appears to be a no‑op in Cursor — created the file with unset ARCH, restarted the cursor-server, and confirmed the bootstrap process still has ARCH=x86_64 directly in its /proc/…/environ.
Both the VSCode code-server and the Cursor cursor-server launcher scripts are identical (“$ROOT/node” ${INSPECT:-} “$ROOT/out/server-main.js” “$@”), so the divergence is entirely in the layer above — i.e., how the bootstrap invokes check-requirements.sh and whether it reads server-env-setup.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor