# New remote terminals retain removed shell environment variables

New remote terminals retain removed shell environment variables

Status: draft, NOT submitted. Suggested category: bug report / usability improvement.

Environment

Cursor 3.20.21 (reported VS Code base 1.128.0), Linux Docker container, Bash. Exact attachment extension/version not confirmed.

Observed behavior

C_INCLUDE_PATH and CPLUS_INCLUDE_PATH were exported in ~/.bashrc. After commenting out those exports, newly created integrated terminals still started with the old values. GCC consequently included Clang resource headers and failed. Running Ninja without these variables succeeded (74/74, exit 0).

Selected /proc environment inspection showed:

  • Container PID 1 and Cursor main server: neither variable in initial environment.
  • Cursor extension host and multiple newly created terminal Bash processes: both variables present at process startup.
  • ptyHost: neither variable in initial environment.
  • Remote Machine/settings.json did not set them. Other client/attachment configuration was not fully inspected.

The installed server bundle contains a shell environment resolver caching its promise (Ju || (Ju = ...); return Ju) and an extension-host environment merge of process.env, resolved shell environment, and explicit remote environment. This proves caching exists, not the precise terminal injection path.

A clean independent Bash startup after removing the exports did not recreate the variables. Restarting the remote service produced a clean new server; a client-created terminal after reconnect has not yet been verified.

Proposed minimal reproduction — not independently executed yet

Use a disposable container and an inert variable:

  1. Ensure CURSOR_ENV_CACHE_REPRO is absent from the container baseline.
  2. Before connecting Cursor, add export CURSOR_ENV_CACHE_REPRO=before_change to ~/.bashrc and ensure login startup sources it.
  3. Connect Cursor, create an integrated terminal, and verify printenv CURSOR_ENV_CACHE_REPRO prints the value.
  4. Delete the export without adding unset.
  5. Close the terminal and explicitly create a new terminal, not a restored session. Check the variable again.
  6. Compare with a clean independent container exec shell loading the same configuration.
  7. Test persistence disabled, reconnect/window reload, and remote-server restart separately.

Suspected outcome: newly created integrated terminals retain the removed value while independent clean shells do not.

Requested clarification / improvement

Shell environment inheritance is documented VS Code behavior, so this report does not claim caching itself is a bug. Please provide a discoverable command to refresh the remote shell environment for future terminals, or clearly document snapshot lifetime and the required refresh action. Clarify ownership: Cursor, container extension, or upstream VS Code.

This does NOT request mutating existing shells or interpreting removal of an export as deletion of every inherited variable. No evidence shows arbitrary exports in one terminal being copied into another.

The forum request returned Fetch error: fetch failed, so no post was created. This report excludes credentials, internal network details, and private project information.

Hey @xx_w,
This is expected behavior Cursor inherits from VS Code’s remote setup (the server resolves your shell environment once at startup and reuses that snapshot), not something on your end.

To refresh it: open the Command Palette (Ctrl+Shift+P) and run Kill Remote Server and Reload Window (listed under Remote-SSH or Dev Containers - type “Kill” to find the right one). That restarts the server, re-resolves the environment, and terminals created afterward start clean. A plain window reload won’t do it - the server itself has to restart, which matches what you saw when you restarted the remote service.

Terminal-only options if you’d rather not restart:

  • Add unset C_INCLUDE_PATH CPLUS_INCLUDE_PATH to ~/.bashrc.
  • "terminal.integrated.env.linux": { "C_INCLUDE_PATH": null, "CPLUS_INCLUDE_PATH": null } in Remote settings (a null value removes the key).
  • "terminal.integrated.inheritEnv": false in your local User settings (it’s application-scoped, so Remote settings won’t apply it).

One caveat: those settings only cover terminals. Commands the agent runs share the same server snapshot, so the restart is the only way to refresh that path. On ownership - this lives in the remote server layer carried over from VS Code, not the container extension.