Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
When an editor tab is pinned, and that file is later updated (e.g. by an Agent edit), opening the same file from a chat reference/link causes the tab to become unpinned.
This is unexpected: opening an already-pinned file from chat should keep the pin state.
Steps to Reproduce
1.Open a file in the editor and pin the tab.
2.Ask the Agent (or otherwise apply an edit) so that the pinned file is modified.
3.From the chat, click the file reference/link to open that same file again.
4.Observe the editor tab.
Expected Behavior
The tab remains pinned. Focusing / reopening an already-pinned file from chat should not clear the pin.
Operating System
Windows 10/11
Version Information
Cursor Version: 3.14.7
VSCode Version: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Quality: stable
Additional Information
Seems specific to the chat → open-file path (not when simply switching to the already-open pinned tab).
Possibly related to chat opening the file via a different editor URI / reopen path that resets sticky/pin state.
Similar class of issue: tab order/position can also change when applying code from chat.
Does this stop you from using Cursor
No - Cursor works, but with this issue
When this happens, is your editor split into multiple groups (files side by side), or is the pinned tab in a single group?
In a split layout, clicking the file link in chat can open a fresh copy in the focused group instead of jumping to your already-pinned tab - which looks like the pin reset. That’s not intended and not anything you misconfigured; if that’s your setup, we’ve let the team know and it’s an issue we’re tracking.
If it’s happening with a single group (no split), a short screen recording would help - I couldn’t get the pin to drop in a single-group layout on my end. I’ll follow up here as I learn more.
Thanks for the follow-up. Here’s a short recording of the reproduction.
Setup
- Single editor group (no split) — both files were pinned in the same group.
- Before the agent update, I pinned:
pinned_target_a.txtpinned_target_d.md
Steps
- Pin the two files above.
- Ask the agent to update both files.
- Open each file from the chat file links.
Result
pinned_target_a.txt — pin stayed.pinned_target_d.md — pin dropped after opening from chat.
Paths
- Stayed pinned:
D:\OneDrive\git_work\dev-workspace\temp\cursor-pin-repro\pinned_target_a.txt
- Pin dropped:
D:\OneDrive\アプリ\remotely-save\Obsidian\temp\cursor-pin-repro\pinned_target_d.md
So this wasn’t a split-group “open a fresh copy in the focused group” case. The failing path includes Japanese (multi-byte) characters (アプリ), while the ASCII-only path kept the pin. That path encoding difference may be related.
Happy to run any additional checks if useful.
Thanks for the recording. I
The non-ASCII path (アプリ) is distinct, and we’ve shared it with the team. This isn’t anything you misconfigured - reopening an already-pinned file from chat shouldn’t drop the pin. It’s an issue we’re tracking, and I’ll follow up here as I learn more.
Since you offered: one quick check that would help narrow it down - if you pin a file with a non-ASCII name inside your primary dev-workspace root (same root as pinned_target_a.txt), have the agent edit it, then open it from chat, does the pin drop there too? That would tell us whether it’s the path encoding or the separate workspace root doing it.
Thanks for the follow-up, and for tracking this.
I ran the check you suggested: I pinned dev-workspace/temp/テスト/test.txt (non-ASCII folder name under the same primary workspace root as pinned_target_a.txt), had the agent edit it, then opened it from the chat link. The pin did not drop.
So in my case, a non-ASCII path under the primary dev-workspace root does not reproduce the issue. That points more toward the separate workspace root / Obsidian path (アプリ etc.) than non-ASCII filenames alone.
Happy to run any other comparison if useful.