Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.56.2 OS Version: macos big sur I am unable to find any record of someone else having this problem! Can someone point me to how I can start to debug this issue? Steps to Reproduce: a file with some text in it: using a relative path, the file opened is blank: opened using an absolute path, the text is correctly rendered: One hint is that when i edit the file (after opening with a relative path), vscode displays this error: ! Presumably, the code CLI is not using the cwd to open the relative path, and is assuming is a file in the filesystem root. I know this is super weird and am very eager to debug! Has anyone seen anything like this before? I have already tried disabling extensions, looking into logfiles etc.
/duplicate
do you by chance have a environment defined?
Aha! I do! How did that get set?! I've an unset to my shell profile but wondering how it is that this variable is being set in the first place.
I would like to understand how this variable can end up in your terminal environment. We do set it from application code here: But this cannot end up in the launching terminal imho... If you have any clues how you got there, please let me know. Also: I assume you are not using the integrated terminal right? //cc for terminal experts, maybe you have an idea how something we write from JavaScript can end up in the terminal environment.
The terminal environment code is a little complex, but except for cases like being set for extension terminals or getting contributed via an extension, this variable is meant to be sanitized in the terminal's process:
yeah I was also thinking that any prefixed environment variable would not make it to the integrated terminal, but would be good to ensure we have not regressed. However, here I actually think, people use the external (OS) terminal and still see set, which I cannot explain how that can happen from a process launched by the terminal.
Can confirm! This issue concerned using an external terminal to launch a vscode window!
is it at all reproducible for you somehow?
I see we only sanitize the external terminal env on Windows.
I think so! If I remove the unset from my zsh profile then the issue arises again, so it's reproducible in that respect. Is that what you mean?
how do you open terminals for using them? via a command VSCode provides or via Finder/Dock?
Usually the Finder/Dock variety (specifically, entering the letter "t" into spotlight and hitting enter without looking).
I cannot explain this issue then. If you are always opening terminals from the dock, none of the environment variables that VSCode defines should be there. Here is what I think can happen (correct me if you do something different): you open VSCode (either dock or terminal, doesn't matter) at one point you open a external terminal from VSCode (through some command or action) you type in that new terminal it fails to recognise the current working directory if now you open a terminal using dock or finder and try the same () it works
That all sounds right (I do sometimes open terminals from vscode!), except the issue arises even when the terminal is opened externally (via FInder). My immediate issue has been patched (via unset in zsh profile) and I'm alright to drop the concern if this is likely to be something extremely specific to my setup!
I cannot explain that. A terminal that is opened via finder can only contain environment variables as configured by startup scripts ( et al) to my knowledge. But happy to learn how this can happen otherwise...
Ok cool! I'm running some grep -r to see if anyone else might be sneakily setting this variable. Thanks for all your help!
I started seeing this issue after upgrading to MacOS big sur. Even when vscode is not running, the $VSCODE_ env variables are set when I open a new terminal from the dock
I think I figured out the cause of this for me at least. I have zsh set up to auto load tmux. so when a integrated terminal in vscode is launched it creates a tmux session and the env from that somehow leaks into other tmux sessions. I just disabled tmux auto loading and the problem disappeared.
Do you by any chance use tmux inside the integrated terminal in vscode ?
I do not!
maybe this is a red herring, in my testing when I run the command to open an external terminal, I do not see any of VSCodes environment variables appearing. Though it is true that we do not call the method in: Meanwhile I pushed to make sure we never on macOS/Linux, so this issue should not be present anymore.
are the verification steps in the original issue still valid/could you give some?
Yes the verification steps in the original issue are still valid one second. writing better instructions
to verify, close vscode open an external terminal and modify an environment variable in a repo directory starting with for example. open vscode and launch an external terminal from that same repo confirm that the environment variable you set is not present

Related discussion:
text: } if (envVars) { <del> for (let key in envVars) { const value = envVars[key]; </del> <ins> // merge environment variables into a copy of the process.env const env = Object.assign({}, getSanitizedEnvironment(process), envVars); for (let key in env) { const value = env[key]; </ins> if (value === null) { osaArgs.push('-u'); osaArgs.push(key);