Hey, thanks for the report. This looks like a regression from a recent update where the file explorer stopped checking whether an editor group is locked before opening a file in it.
The team is aware of similar editor group targeting issues, and I’ve flagged this specific locked-group regression for them.
As a workaround for now, click into the unlocked editor group first, then open the file from the explorer. It should use the active group if it’s unlocked.
Let me know if anything changes or if you notice any related issues.
When an editor group is locked via “Lock Editor Group”, new files opened from the Explorer or Quick Open (Cmd + P) still appear in the locked group instead of being redirected to an unlocked group. This defeats the purpose of locking a group entirely.
This appears to be the same regression reported in Locked editor groups don’t redirect file opens to unlocked group, and the issue persists in version 2.6.21.
Steps to Reproduce
Open Cursor with a project
Split the editor into two groups (e.g., left and right)
Right-click the tab bar of one group and select “Lock Group”
Click on the locked group to make it active
Open any file from the Explorer sidebar or via Cmd + P
Expected Behavior
New files should open in an unlocked editor group, regardless of which group is currently active. The locked group should remain untouched with only its original tabs.
Actual Behavior
New files open directly in the locked group, ignoring the lock state. The locked group behaves identically to an unlocked group when opening new files.
+1 this completely breaks my workflow as I run the Claude Code VS Code plugin in a locked editor group on the right, so my focus is usually in that editor group when prompting, but I never want code files to open in that editor group. I will probably have to switch to VS Code until this is fixed.