Allow to configure editor auto reload behaviour

[dmlemos]

VSCode Version: 1.10.2 OS Version: macOS 10.12.3

Steps to Reproduce:

1. Open editor
2. Modify a file in your git repository, but don't save it
3. Checkout a different branch that touches the same file
4. Go back to the editor and try to save
5. ERROR: "Failed to save 'file1': The content on disk is newer. Click on Compare to compare your version with the one on disk."

Personally I would like to see the files being reload from the disk every time without prompt. With git I don't have to worry about losing history. Similar to how SublimeText works. When the files change in disk (ex: change of branches), they get automatically reloaded, independently of their current state in the editor. I prefer this behaviour, rather than having to confirm reloads.

With that said however, there must be options for all the use cases. Many people prefer to be notified of changes in their files! Suggestion to add an editor.autoReload parameter in order to control this behaviour. Possible values:

• Always - reload from disk without prompt
• Confirm - show a prompt confirmation to either accept or discard the changes
• Backup - show the file with the new changes automatically, but always backup the old state to 'filename.bak'
• Never - current behaviour?

Evolved the idea from @rmunn on #23043 issue. Decided it was best to create a separate issue for this.

EDIT: Made it clear that it is mandatory to implement this feature with all the use cases in mind, and added new options.

[marcelocantos]

For unedited files, VSCode's behavior is already optimal (auto-reload without asking) bar the suggested improvement in #23043.

However, always is dangerous if there are unsaved edits. I guess if people want to opt in to this, they're their tears to make, but I'm not sure this is such a good idea.

[offero]

I sometimes get this message but there is no difference between what is on disk and what is in the editor. Maybe I added and removed a character, but there is no difference.

[bpasero]

There are related issues that ask for a confirmation dialog when files change on disk: #14298, #20876

Let's keep this issue around for the desire to have a setting to always overwrite a file if it changed on disk even if it is dirty.

[WilliamStone]

Comment from closed issue #41250, which presents a scenario that auto-reload behavior differs by file path pattern. So it may be appropriate for auto-reload option to set behavior not globally, but based on file path pattern, e.g. D:\Dropbox\**\*.* File path pattern can also cover file-type option scenario by file extension, e.g. D:\Java\*\\.java

[maximelafarie]

Is there anything new? I'm having the same problems. For example, I make an error that will be underlined, then to make it go away I have to go to another file tab, then back to the file tab where the error was detected to get vscode to refresh the entire file.

Is there an option to disable the cache if there is one, or to automatically trigger a new file check? 🤔

[Raydir]

@bpasero you wanted to know why it is important to get a notification if a file is changed outside.

As for me (and my related users) it is absolute necessary to get a feedback when someone/something did change the content of the file since many of our source files are not compiled and not checked in in something like e.g. GIT.

Example: Some of our scripts are textbased and it happens that you work on a file for hours. If i'm working on a file and go to the toilet or gettin a coffee i'd like to know if some part of my code has been modified meantime.

Perfect would be if one can see the changes alike when you compare it to the content in your clipboard

So my wish would be to have a setting to get a message if changed, check the changes in the diff-view and agree or decline the changes.

[bpasero]

My current challenge with this feature is that I cannot easily distinguish a change done in the editor (VSCode) from a change done externally. If someone has suggestions how to distinguish these two, please speak up. I would never want to show the confirmation to show up for changes done by the user in the editor.

Another question is wether this notification should show up for tabs that are opened but not active. I would find it quite disturbing to get spammed by notifications for each file that was changed if it is not the active file I am seeing.

[Raydir]

@bpasero I agree with you on your latest point - the message should pop up when you get focus to a file and it has been changed outside.

[bpasero]

@Raydir is that true though? What if you have focus in the editor and trigger the command to pull from Git and changes come in, would you not want to see a notification then too?

[Raydir]

For me it is only needed when i am working on a file. if you get the file from e.g. GIT you want to get the changes / latest version. That's not the same i'd say.

If you pull from GIT and due to this you are looking your changes it's your own fault... But you are only loosing work if someone is changing the SAME file while you are working on it.

Think about this one: You have thousands of lines of code finished and now you are do some refactoring at the beginning of the file. If someone is changing content at the bottom you wont even notice that it has been changed at the moment.

[bpasero]

@Raydir but how do changes to a file come in if not by explicit decision from you? It is not like 2 people are working on the same file and the changes come in without you doing anything unless maybe you actually had a shared remote file system that constantly pushes changes to your disk?

[rmunn]

@Raydir - This is a little bit off-topic in this bug discussion so I won't belabor the point beyond this single comment, but this phrase causes me serious concern:

many of our source files are ... not checked in in something like e.g. GIT.

I would urge you to fix this situation as soon as you can. You are working without a safety net, and causing yourself unnecessary pain by doing so. Using Git as a programmer is like using saves when playing a video game. Yes, you might be able to get by without it... but then there are some mistakes you can't recover from, and you're in danger of having to start from scratch if your mistake is bad enough. A git commit is like saving your game: it gives you a checkpoint that you can always go back to if you need to. The peace of mind that comes from knowing that I can't lose more than the past few minutes of work is immense. If you have "thousands of lines of code" as per your previous comment, and it's not checked into Git, you could lose ALL of that with just a single careless mistake. Please don't do that to yourself: start using a DVCS (Git, Mercurial, whatever) as soon as possible so that you have a safety net.

[siran]

My current challenge with this feature is that I cannot easily distinguish a change done in the editor (VSCode) from a change done externally. If someone has suggestions how to distinguish these two, please speak up. I would never want to show the confirmation to show up for changes done by the user in the editor.

Another question is wether this notification should show up for tabs that are opened but not active. I would find it quite disturbing to get spammed by notifications for each file that was changed if it is not the active file I am seeing.

Just an idea, but you could probably cache the modified timestamp and see if it changes.

You could do this check everytime a file tab is focused (I agree it can be disturbing otherwise). Yet, other editors notify you on for all opened files (I suppose there is a timer somewhere). Both behaviors can be useful.

[bpasero]

Just an idea, but you could probably cache the modified timestamp and see if it changes.

Yeah we do that already but in certain file systems this has proven to not be reliable (e.g. network shares).

You could do this check everytime a file tab is focused

I think that does not cover the case of you invoking a keybinding to pull in changes from git and the active file changing. There is no focus loss in that case, yet you probably still want to be notified.

[Raydir]

@rmunn You probably should know that that is not really my decision (I'm just the person that tries to reduce the problems related to this) and that I DO know what e.g. GIT is or what would be the benefits. This part of source is customer related and I can't just change that situation since this is a 30 years old situation. We DO backups of those files. But not with something alike GIT and i can't controll the backup if the customer is doing hardware maintenance himself...

@bpasero
Those files are on a network share and there IS the possibility that more than one person is working on the same file - but not intentionally. And exactly THIS is the problem. So the problem is, that one person is working on a feature and another one tries to fix a problem related to that file. Et voilà...

If you don't have a file lock alike Visual SourceSafe did n'or a message like Notepad++ does, you wont notice and you can't react to or decline the change.

[Raydir]

@bpasero if the editor would open files exclusivly (lock) the problem would not exists tho.

[bpasero]

Those files are on a network share and there IS the possibility that more than one person is working on the same file

Wow, that is a crazy work environment...

Even if we implemented a notification prompt, file events over network shares are so unreliably (actually not working) that it would probably not work even if we implemented this with our file watching infrastructure today.

[Raydir]

For me I will leave this point since I guess I made my point clear...
If the feature is not possible so should it be. Kind of strange tho, that the other guys that did wish this feature are not commenting again.

To clearify... it's not our base source that is "open" it is the customer specific part that can be implemented/changed to customer needs. The execution is server based. To change a file the customer / project leader/ customer dev has to connect to the server - with a networkshare or RDP or what-so-ever.
Even when you open the file from RDP the problem still persists since the file can be opened by several peoples at the same time. So not the network-share itself is the problem and not the case of this discussion.

@bpasero i won't comment the "crazy work" environment...

[bpasero]

@Raydir but in that environment you constantly must have conflicts, or not? I only see this working if the file could actually be locked by you and then no-one else can make an edit until you release that lock?

[bpasero]

Also, I have not seen an editor/ide that prompts you on a change and offers you the ability to diff your changes with the ones on the server. So if you see a prompt and you get asked to either drop your changes or overwrite the remote ones, what do you do in that case without knowing what the changes have been?

[Raydir]

No we don't since normally it is the project leader together with the customer. When building new processes there are specific files that handle events. Those can be problematic when several issues are implemented by different peoples.

As said before - to open a file exclusively like possible in e.g. Textpad would be sufficient. The point with the "diff" would be a perfect addition - if not possible that's not a killer criteria for me.

[BillDenton]

This is how Visual Studio 2017 handles files changed in the background: This is the kind of behaviour I would like to see Visual Studio Code.

[arnaalg]

We have encountered several situations where a promt like shown above from Visual Studio 2017, or below here from NotePad++ or UltraEdit, would be very welcome.

NotePad++

UltraEdit

1. Settings- / project-files that are written to by open applications while being edited in VS Code: For instance during FPGA development. We often work with manual modifications on .qsf-, .sdc-, .cof-, tcl-files in an editor at the same time as we run compilation, synthesis, timing-analysis, simulations or other operation from the open Quartus application. Quartus writes it's own things to the same files. For instance we could imaginge changing the paths of the source files in the *.qsf file, then Quartus overwrites these paths with the old ones without any notice. You check in the file, and the build server builds the project using the wrong source files.

2. Working with VHDL files in VS Code and compiling in Quartus. If compilation fails you jump directly to source by clicking on error message output in quartus. This typically opens the internal text editor of Quartus. Apply changes here, save file and re-compile. This scenario might not be as dangerous since the changes are manually done by yourself in another editor, but it would be super useful to get that promt as a confirmation/reminder. Don't forget that there might be enough coffee-cup refills or pee-breaks between these events to forget what you were doing.

[arnofly]

Same request than @BillDenton or @arnaalg

We can imagine that this option works like this: You split your file on the same window in VS Code. So, you have 2 views of the same file with one tab is active. The active tab could be autorized by the user to auto refresh the file if this one is modified by an external program (I mean with or without a prompt, depend user prefs). The inactive tab(s) keep the old version(s) of the file.

I instinctively tried to do this with VS Code 1.30.2, but the software refresh all views.

[BarryBo]

I just had data loss due to this. This would have worked in VS2017, but didn't in VSCode... I had VSCode open with a particular file open, but saved to disk. I then used 'git checkout --' to undo the changes in the filesystem. I expected the VSCode in-memory version of the file to stay around while I did git operations underneath. I then planned to save the VSCode version on top of the filesystem version.

In VS2017 I get a warning about the file changing underneath the editor and have a choice of whether to reload or not.

In Code, I get no warning, and the automatic reload lost my changes.

[ezel3]

I lost 4 hours of work because of this. I was working on a program on a Linux box, and copied the previous version back with WinSCP for inspection. Instead of asking if I wanted to load the changed version VSCode did so all by itself. All my work was overwritten. This is not funny and absolutely not intuitive. Please add a possibility to disable this behaviour or add a prompt like BillDenton and arnaalg described above.

[tstauffer]

What is the resolve here? I agree with so many others that this needs to work at least as well as Notepad++. this is very frustrating

[escaner]

Could we have this feature asking whether to reload the files or not, please? Actually this prompt should also appear when another vscode instance modifies a file and both buffers are not synced. I even prefer having to confirm a "git pull" over the risk of losing work on an automatic load of an externally modified file. This feature has saved me several times over decades of software development in other editors and I do not consider an editor that changes files without my consent fit for serious work.

[tstauffer]

one thing i have done to mitigate the issue is install LocalHistory xyz. in this way, you can still get back to what you had. To be quite honest, this even happens in my regular git development areas and I have to rely on the IDE's local change repo to save my bacon at times.

[Encoder42]

Just started using VSCode which has really great features and customization possibilities. Thanks for releasing it as open source! Soon I discovered the automatic reload without notification or the possibility to keep the current document without reloading. This seems very critical and dangerous to me and could prevent me from using VSCode as my new favourite editor.

Blocking pop-up windows (as used by many other editors in such a case) are very annoying (especially if updating many documents, e.g. using git) and would disturb the nice user experience of VSCode.

I would suggest a concept as used in Geany (www.geany.org) which inserts Information in the document window and allows the user to choose what to do without blocking. (E.g. you can postpone the choice and edit another document first)

Geany 1.34

A nice configuration option for VSCode could be:

• "editor.fileReload": "auto" same handling as today with automatic reload without notification

• "editor.fileReload": "notify" automatic reload as today but with geany style information in document window and marking of tab. The info box could allow to:

  • [Undo] - restore previous editor contents
  • [OK] - acknowledge change

• "editor.fileReload": "ask" marking of document tab and geany style information to allow the user to choose what to do:

  • [Reload] - reload document from disk
  • [Overwrite] - write current editor document to disk
  • [Diff] - show differences between current document and file on disk
  • [Cancel] - do not read or write disk, keep editing current document

[rob-miller]

I just got bit by this. A friend warned me about it when I had just started using VSCode:

One major issue is that it watches files on disk for changes and loads them without asking. If something trashes your file, you can't fix it by writing the editor buffer.

In my case I have autosave enabled - so my copy in memory not dirty. For unknown reasons (1) my NAS had powered off and (2) when I restarted it, it sync'd my source file from the NAS instead of the correct direction based on the timestamp (normally works great and luckily it was only a few minutes of work). I've re-done the work and now not sure if the part I lost was there in the undo buffer or not.

As the Local History extension text describes this 'your workspace has a catastrophic problem'. I'll be installing that extension now though I'm not sure it would have saved me from [some other process messing with my files]. For me the lost work was there in VSCode and it disappeared before my eyes; normally yes, I want it be able to reload from disk if I go and use another tool to refactor - but still nice to have a warning and an option to do something before my work disappears.

[brianhansonxyz]

I have a code formatter that runs on save that takes about 1 second to execute. If i hit ctrl+s and keep typing, then the formatter will reformat the document on disk and not reload the open file, and then when I try to save again, the IDE says the file on disk is newer. In this scenario I always want to differ to the editors version of the file and not the file on disk, but I still want to allow the automatic reload if the file in the editor is unmodified. For this reason, I would love the option of "always overwrite files on disk" rather than forcing me to diff and discard the changes on disk. So, +1 for this feature request.

[brianhansonxyz]

I wanted to share that I found that if the file's modified time doesn't change, the IDE will reload the file if it has changed, but if the user starts typing in the IDE and the file changes, then the disk changes are ignored and the ide changes will save without complaining about a file modified error. This allowed me to fix the issue in my workflow but I am not sure if it will work for anyone else's scenarios.

On Tue, Mar 19, 2019 at 3:17 PM kanlukasz notifications@github.com wrote:

Its really important feature. For example if i look in live server logs or debug logs, i would to know if file is changed at this moment - the prompt to reload the file if its content has changed, is necessary here

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/23107#issuecomment-474562451, or mute the thread https://github.com/notifications/unsubscribe-auth/ApT7sX8E2qRHfsVzxOYd4GYx7d0ZJ1-7ks5vYUXPgaJpZM4Mm-XH .

[kanlukasz]

My two cents about that:

From what i see, Visual Studio Code automatically reloads opened file when changes occur 🙅‍♂ I talk about behavior from Notepad++ which is extremely useful 😱

Why we need this? For example:

➡️ If the currently opened error log file is changed - it's good to know that ➡️ If I make a mistake and change the file in another program - it's good to know that

[piotr-kubica]

For me Ctrl+Shift+P followed by command "Clear Editor History" fixed the "The content on disk is newer. Click on Compare to compare your version with the one on disk." error message. (Git repo was clean, files was not opened by another editor)

[m-7761]

For the record, I don't see the files being reloaded when I edit them. Maybe because the project is bound to a WSL symlink. (When I followed the tutorial to run the "code ." command in the project folder it didn't pick up on the symlink, and used the default WSL installation instead of the one the shell was running in. No further comments. I was able to adjust it to do so.)

Vscode is really nigh impossible to use as a text editor. It's so unorthodox, and treacherous. In this state I would feel much better if it were a read-only view for debugging with breakpoints only. It's very promising for its utilities but lacks very basic functionality that could probably be shortlisted in less than 10 issues, compared to thousands in the backlog. I worry those are distractions. It could be popular with a better layout, ideally flexible like Visual Studio. It's called Visual Studio Code after all. Please emulate VS more. Doing multi-platform development I've multiple editors and tools open working on the same files. I don't have a perfect memory, and currently vscode isn't keeping the file up-to-date even if not modified in vscode, so I only know to close vscode, and reopen it. At least it opens to where it left off.

It's very good, but it's a shame it doesn't have the feature set of the crudest text editors. It's not really an editor. It's more like a webpage with a text form. EDITED: It's also unnatural that the CMake build extension seems to build from the edit buffer instead of the file on disk. I don't know how else to describe my experience. It seems impossible, but that seems like what's happening. (I edit the file externally, build with vscode, debug, the build is using the vscode code, build externally, and it's using the code on disk. IOW, vscode doesn't seem to have overwritten the file on disk. It sounds neat if true... but I think in practice just confusing, and limiting.)

[ultrafs]

@bpasero so which bit of this aren't you getting?

i've just started using VSC,, looking to use it as default editor. all good... until i just came across this problem. text in open file in VSC updated externally without letting me know! lost a load of stuff i was buffering before copying and pasting elsewhere

vscode SHOULD NOT be updating ANYTHING that is open in the editor without letting the user know! As people have said above... all the editors show this simple and obvious behaviour.

our working practices and or environments are none of your concern. you should do what is standard practice for an editor - namely ask the user if in doubt!

one of the minor uses for this (normal) function is just to confirm that a file has been updated fron code i'm writing/debugging in VS(2019) - and or that's it's writing the correct stuff - not what VSC thinks i ought to have in the file!

Sort this out ASAP. this is a MAJOR flaw in an otherwise great editor.

(unless my settings are wrong or something)... if i (or who/whatever) updates a file outside the editor and i have that same fileo pen in the editor.. when i save it (ctrl-s) i dont even get a warning that the version on disk has been updated/newer. is there a setting for this somewhere?

Shame all that setting up over the last couple of weeks has proved a waste of time - back to NP++ it seems

[minig0d]

So here is a perfect situation as to why this behavior needs to be disable-able... I'm fighting with Wordpress intermittently deciding it wants to overwrite my .htaccess file...

So what seems to be happening is I make a change and save it in vscode, And every once in a while, Wordpress is using a cached copy, making changes to the cached version, and then overwriting my version.

Since VSCode thinks it's in an "unchanged"/saved state, it reloads the changes and they are wiped off my screen without warning.

At absolute MINIMUM the old file version should be added to the undo history (but still not ideal).

But while editing with Notepad++ (which I'm finally trying to transition from to Code) I get the ideal behavior (as the others have mentioned) of it saying the file has been modified and I can just click NO to reloading it, then save and overwrite my changes back to the file with no work lost.

As some of the other users mentioned above, it's kind of not cool when their opinions/requests are dismissed because it doesn't align with how the developer thinks it should be used.

Sure the auto-refreshing is cool if two people could be editing the file somewhat asynchronously or log files or whatever, but I would think the risk of DATA LOSS should be a much higher priority than a "cool factor". Since VSCode doesn't have file locking and MANY developers who work in teams utilize all kinds of network file systems (many of which don't support file locking), the assumption of a file saved state seems pretty risky (ex. in a case of high latency or "crossed paths" (simultaneous changes).

Just my 1 cent FWIW...

[siran]

I've been wanting an auto-reload setting to show/not show a dialog for ages. I don't know what's the holdup or why it's a big deal. However, you can always edit the file with a space, for example, and VSCode will not change you edited file. Also, in my experience the previous version of the file is the undo history. I still don't know how to get notified if the file has been changed, though.

[minig0d]

However, you can always edit the file with a space, for example, and VSCode will not change you edited file. Haha that's a good idea... I'd probably forget to put a space though... so then I'd have to write an extension to add a space for me so the file was always dirty... then I may have autosave turned on and it would go into an endless loop and fry my computer and end the world... all b/c of this "behavior"

Also, in my experience the previous version of the file is the undo history. I've tried several times without success unfortunately.

I still don't know how to get notified if the file has been changed, though. Ya that's one of my main concerns. I can always save a backup of the work, but it's the not knowing that it happened that makes it twice as bad!

[siran]

seems like a little tantrum of the vscode team, not willing to implement this

[escaner]

Siran, the fact that almost three years later nobody is assigned to this issue and that it was described as a feature request when actually an editor modifying the buffer contents without any input or notification to the user should be considered a bug says a lot about how they care about it.

[m-7761]

Well, despite sharing its namesake if VSCode were as professional as Visual Studio Microsoft would see its business VS license pool dry up in favor of vscode.

(It's severely hampered, to be sure vscode stays "baby's first code editor" forever.)

[minig0d]

Well, despite sharing its namesake if VSCode were as professional as Visual Studio Microsoft would see its business VS license pool dry up in favor of vscode.

(It's severely hampered, to be sure vscode stays "baby's first code editor" forever.)

That would definitely explain the prioritization of some of these things... "Oh good data loss,.. people will stop using free stuff and pay for our overpriced stuff now..."

[siran]

I wonder what people like @bpasero can say about this. I've seen some comments in the past that "it was not so easy" or that "there were some problems" with this.

[m-7761]

I wonder what people like @bpasero can say about this. I've seen some comments in the past that "it was not so easy" or that "there were some problems" with this.

If so their excuse is in terms of whatever programming paradigm they're limited to be cross-platform. Every text editor has this feature, and there is no excuse not to, so even if it has to be implemented with platform specific fixes there is no excuse. No professional programmer works like this, but there are a lot of novice programmers, and that's why vscode is thriving, since they know no better. Novice programmers have simple programming environments where it might seem logical to use one editor. Workaday programmers know you have several editors opened to the same files and several tools touching on the same files, and you can't get anything done without this feature.

(I use it to debug WSL which is a read-only application, and even then I must restart it for every run. Debugging Linux apps is so tedious that it's actually the best tool even though its connection to GDB is slow as molasses. GCC specific bugs are the worst since working with it is 30x slower than solving problems with Visual Studio. It takes an afternoon to address single bugs. I don't know how the Linux world is able to function.)

[minig0d]

I wonder what people like @bpasero can say about this. I've seen some comments in the past that "it was not so easy" or that "there were some problems" with this.

I mean given my coding abilities I would never judge easiness, but in talking about open source written in a common language of a function that's been around for decades in tons of similar programs with source code freely available on github for inspiration, it wouldn't seem to be that hard. It's not exactly a fitting a square into a round hole type effort.

One of the fundamentals drilled into our heads has always been that no accidental data loss is acceptable. So while someone could say that we should have backups and maybe with source control you can throw that in there too, but the key point someone made was that there is zero notification. So to we would never know to even know... I mean I was literally chalking things up t midlife crisis, deja vu and that it was just a similar situation but different file, or thinking i had just forgot to hit save and had literally re-invented the wheel multiple times before seeing this.

It's also this appreciation for data integrity that is why I keep backups... but some people to heavily rely on these crutches in lieu of real fixes... as that thread with the guy having lost 3 months of work because of git found out. And a large amount of the replies blamed him rather than the fact that git is far from user friendly and in its 20 year existence could have been improved. I think it just boils down to the mindset and priorities. Are we building a flashy new race car that can go to starbucks and back but may blow up halfway there and we're ok with it or should there be some level of safety?

Sorry /END rant

[minig0d]

Sorry and I'm in no way trying to bash the VSCode team... As many times as it took trying it (I think i uninstalled it about 10 times) before finally getting the hang of it, I do love it now... lol

[m-7761]

Vscode acts like no other editor in the world in this regard. It's not really an editor so much a text browser... like a web browser text area. I can't even remember its rules, that make no sense. I'm pretty sure if you touch a file in vscode it puts an unshared read/write lock on it or something that makes other software's interaction with that file make no sense unless they refuse to open it.

If you don't edit the file I think it changes out from underneath you. But I think editing the file carries over from vscode sessions or something, so that if you edited it, and closed vscode and reopened it, you still have to remove it or change its status in your workspace.... it's all completely insane. I still can't really tell you the rules or if it always knows if its own files were really edited or not.

It's a wonder to me its published software. I guess it was published before it became vscode, but Microsoft's putting its VS stink on it (and really the nonexistence of anything remotely like VS in the Linux world) gives it more clout than it deserves. I'm not a critic, I think some of its integration stuff is amazing, but other things are showstoppers, not just this, and I suspect that may be by design and that it might be called "vscode" because MS got scared and bought it specifically to keep it from competing directly with Visual Studio.

[m-7761]

https://github.com/microsoft/WSL/issues/4064 looks like a compounding factor in this. I don't know how much of the troubles I have with Vscode are this WSL bug or Vscode, a mix I think. I just noticed this problem today affecting programs outside of Vscode.