vscode: Pasting file in the explorer no longer opens that file in the editor
Issue Type: Bug
When I clone a file, the focus for the file has always been the cloned file and so I can start editing that file and straight away.
This behaviour has changed in the last couple of weeks, I have nearly lost valuable code multiple times recently because of this behaviour change and had thought I was doing something wrong, but I have reproduction steps listed below.
I have tested this without extensions turned on code --disable-extensions to rule out issues there.
The following keystrokes (on mac) is a flow that I have been using for years to work on the next (new) class or file in vscode, this flow has recently stopped working as expected.
I have a file opened, I’ll call it original.rb and it is finished and I am ready to move onto my next class/file.

Here are the keystrokes and mouse clicks that I do.
Clone the current original.rb file
Command+S - This saves the file 'original.rb'
Command+Shift+E - This selects the explorer window
Command+C - This copies the current file 'original.rb'
Command+V. - This pastes the current file to 'original copy.rb'
At this point, the focus in the explorer window is the cloned file ‘original copy.rb’ and up until recently the focus in the editor has also been the cloned file ‘original copy.rb’
I now click mouse in the open editor window
Start editing the new file

BUG: This is not the case any more, the original file has the focus in the editor, even though the cloned file has focus in the explorer .
What has happened time-after-time in the last week or two is that I click into the editor with the assumption that I am working on the cloned file, I update it, delete irrelevant methods, add new methods, save my code and then go to run and my build is failing because I was not altering the cloned file, instead I have been destroying the original file.
AutoReveal Settings
I’ve checked the autoReveal settings to see if there was an issue there, but I can’t see any issues.

VS Code version: Code 1.55.0 (c185983a683d14c396952dd432459097bc7f757f, 2021-03-30T16:01:05.981Z) OS version: Darwin x64 19.6.0
System Info
| Item | Value |
|---|---|
| CPUs | Intel® Core™ i9-9880H CPU @ 2.30GHz (16 x 2300) |
| GPU Status | 2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled |
| Load (avg) | 2, 2, 2 |
| Memory (System) | 32.00GB (2.09GB free) |
| Process Argv | -psn_0_53261 --crash-reporter-id 5534e9ef-10e0-4b4d-848e-f05cde38340f |
| Screen Reader | no |
| VM | 0% |
Extensions (19)
| Extension | Author (truncated) | Version |
|---|---|---|
| vscode-tailwindcss | bra | 0.5.10 |
| vscode-postgres | cko | 1.1.17 |
| bracket-pair-colorizer-2 | Coe | 0.2.0 |
| es7-react-js-snippets | dsz | 3.1.1 |
| prettier-vscode | esb | 6.3.2 |
| auto-rename-tag | for | 0.1.6 |
| vscode-hacker-typer | jev | 0.1.1 |
| vscode-csharp-snippets | jor | 1.1.0 |
| vscode-docker | ms- | 1.11.0 |
| csharp | ms- | 1.23.9 |
| mssql | ms- | 1.10.1 |
| python | ms- | 2021.3.680753044 |
| jupyter | ms- | 2021.5.702919634 |
| ruby | reb | 0.28.1 |
| LiveServer | rit | 5.6.1 |
| markdown-preview-enhanced | shd | 0.5.17 |
| code-spell-checker | str | 1.10.2 |
| vscode-ruby | win | 0.28.0 |
| markdown-all-in-one | yzh | 3.4.0 |
A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry914:30276682
pythonvsdeb440:30248342
pythonvsded773:30248341
vstes627:30244334
pythonvspyt875:30259475
pythonvsnew554cf:30281909
pythontb:30283811
openwsldoc:30282072
vspre833:30267464
pythonptprofiler:30281270
vshan820:30276952
pythondataviewer:30285071
vscus158cf:30286554
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 25
- Comments: 29 (9 by maintainers)
Will revert back to the old behavior probably. Assigning to April to investigate.
Fixed via ed5d4a1329a
It depends on how you use the explorer tho, what I personally do with copy-pasting a file is to clone a file and start editing it; and I think this should be the main use of copy-pasting files for the majority of people. this behavior cost me hours of headache today since I was modifying old files like 10 times just in the last couple of hours and had to revert and copy the changes to the new file each time.
So if this is about people complaining, consider this my complaint against this change, if for no other reason except the fact that this was the behavior for a long time and many of us already have this in muscle memory.
However, regardless of my personal “complain”, please make sure that the focus stays on the old file in the tree view if we are staying with this change since it is confusing as hell that we have a file open in the editor but the focus is on the newly cloned file in the tree view
This way of working has been in place for years, and many people use it. If other people are complaining, then you give them the option via settings to the workflow that suits their needs, you don’t just break tried and well worn workflow.
Even now that I know about the issue, I am still copy/pasting and then editing the wrong file because you can’t tell that that you are on the wrong file.
And even if I could tell
It would still add an extra step to the workflow because now I would have to copy the file and then use my mouse to go and open it as well.
That is precisely the problem. Focusing on the duplicated file is what misleading about what you’re actually editing. What explorer are you referring to when the selected file or directory in the tree on the left panel is NOT the one you’re seeing on the right?
I too have wasted numerous hours in the past couple weeks editing the original without realizing it after this change was made.
The double
Enteropens the name changing box once again and does not change the open file.I very rarely add to already discussed topics, but this one is pretty annoying. The double “ENTER” may help, but the copied file should not be shown as selected in the editor tree. Thanks for rolling back the new feature and making this a setting 😉
I screw this up every single time. This caused me at least 100 GPU hours wasted last week. Even though I noticed what’s happening pretty early, I still can’t remember to click the copied file, because it is so counter-intuitive that my brain just can’t handle it. Wouldn’t it be possible to create an option for configuring it?
I’d happily accept that the previous behavior was wrong, but it stood like this for years for people to train themselves on it. The result is pure frustration for those who have adapted to it.
Fully agreed. This change seems to ignore all the people who didn’t complain about the status quo 😄
When you open Windows Explorer and copy/paste a file, the pasted (duplicated) file will be focused.
Okay I opened https://github.com/microsoft/vscode/issues/122586
@oliversalzburg I think the confusion is primarily due to the file that’s being copied is being opened in preview, and is left open when the file is pasted. This ties in to what @jedwards1211 was saying about the different selection colors. If I’m not mistaken the colors actually refer to the state of the selection, which makes the whole thing a bit more complicated.
In the case when a file is pasted, why would the source file remain selected? What happens when you paste a file from an external source, should there be no files highlighted? Suddenly which file is selected in the explorer is dependent on the users preference for whether or not to open the pasted file in a new tab. That seems a bit odd to me.
This behaviour is extremely confusing.
The focus in the Explorer is on the new copy, but the focus in the edit pane is on the old file. That is so counter intuitive I cannot believe this was an intentional change.
IMO one of these two options needs to be made default
What is the purpose of even having a focus highlight on the Explorer pane, if it isn’t to display what file is open?!
I write many test cases in a single day. In the hundreds to thousands.
They’re all plain text files with a certain boilerplate format and it’s convenient to copy-paste them and tweak a few lines to test potentially troubling edge cases.
At some point, after updating recently, the behaviour changed. However, in my case, the names of files don’t really matter, which makes things worse.
I have found many files where the test case does not match the file name describing it, because I copy-pasted a file, clicked on the pasted file, renamed the pasted file, then modified the original file instead of the pasted file by accident.
I’ve been trying to train myself to work around the issue by double checking the name of the editor tab that’s focused… It’s not going well. I still mess up a lot.
In Visual Studio 2019, if I copy-paste a file, and click on the pasted file (once), it opens the file in the editor and focuses on it. Then, I can rename the pasted file, and start editing the pasted file without worrying about overwriting the original by accident.In VS Code, a single click doesn’t open and focus on the pasted file.Sorry
[Edit]
Okay, I just paid more attention and in VS 2019, the pasted file is not selected the tree view. So, this forces me to click on it to rename, which opens the file in the editor and focuses on it.
In VS Code, the pasted file is selected in the tree view. So, I instinctively hit
F2to rename the file, and expect it to be open and focused in the editor already, which is not the case.Clicking the pasted file to select it in the tree view (even though it’s already selected), does open and focus it in the editor.