File Refresh upon Branch Switch

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Opened Files in the editor are not automatically getting refreshed upon branch switch

Steps to Reproduce

Open File in IDE
Switch the branch in terminal
New Branch Changes for the file are not automatically reflected in IDE

Expected Behavior

Files should be automatically refreshed as per the branch we are switching to

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.69
VSCode Version: 1.99.3
Commit: 63fcac100bd5d5749f2a98aa47d65f6eca61db30
Date: 2025-11-07T18:21:29.650Z (6 days ago)
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the report. To help diagnose this, could you please let me know:

  • Does reloading the window help? Try CMD+Shift+P > “Developer: Reload Window” after switching branches. Does this refresh the files correctly?
  • Does it happen with Cursor’s Git UI? If you switch branches using Cursor’s built-in Source Control panel instead of the terminal, do files refresh properly?
  • Any console errors? Open Help > Toggle Developer Tools, go to the Console tab, then switch branches in the terminal. Do any errors appear?
  • Extensions check: try running Cursor with extensions disabled (cursor --disable-extensions from the terminal) and see if the issue persists.

This might be related to file watcher limits on macOS or an extension conflict. Let me know what you find.

Same problem here – when I git checkout another-branch my edit history gets contaminated with tool cache information. It’s so bad that even Cursor recognizes it after some prompting and putputs

```

Tool cache is stale. Using sed directly:

Diff is clean now:

| File | Changes |

|------|---------|

| `_init_.py` | Removed `linear_fp8_forward` wrapper (-32 lines) |

| `linear.py | Comment update only |``

Nevertheless, at this point mainy files have been polluted and even committed!

This also on MacOS. Version
Version: 2.1.49
VSCode Version: 1.105.1
Commit: 21a2ed198584d56a91c0b996d1a09c93f8538440
Date: 2025-12-05T07:49:06.016Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.0.0

Said cursor:

```
The search didn’t find anything specific to Cursor AI’s tool cache issue. This appears to be an internal Cursor behavior, not something with a published extension.

What we experienced: The read_file and search_replace tools showed stale content after git checkout, causing the corruption where legacy-branch code leaked into edits.

Practical workarounds:

  1. Use terminal commands to verify file state before editing:

    cat | head -50 # See actual disk content

    git diff # Confirm no unexpected changes

  2. Force file reload in Cursor:

  • Close and reopen the file

  • Use Cmd/Ctrl+Shift+P → “Revert File”

  1. After git checkout, run a quick verification:

    git status --short

    grep “<known_pattern>” # Verify expected content

  2. For critical edits, use sed directly (as we did) rather than the search_replace tool if you suspect cache issues.

This is likely a Cursor bug worth reporting to their team. The AI tools should invalidate cached file content when git operations modify the working tree.
```

The web search is malfunctioning. Here’s a prepared bug report - you’ll need to submit it manually to forum.cursor.com or via Cursor’s in-app feedback (Help → Report Issue):


Bug Report: AI Tool File Cache Not Invalidated After Git Operations

Environment:

  • Cursor Version: [check Help → About]

  • OS: Linux (Ubuntu)

  • Git version: 2.x

Description:

The read_file and search_replace AI tools return stale/cached file content after git checkout or git checkout origin/main operations. This causes the AI to make edits based on outdated file content, potentially introducing code from other branches.

Steps to Reproduce:

  1. Open a workspace with a git repository

  2. Have the AI read a file using read_file tool (e.g., test_scales.py)

  3. Run git checkout in terminal (branch with different content in that file)

  4. Have the AI read the same file again using read_file

  5. Observe: AI tools show content from the PREVIOUS branch, not the current checkout

Expected Behavior:

After git checkout, the read_file tool should return the actual current file content from disk.

Actual Behavior:

read_file returns cached content from before the git checkout. The search_replace tool also uses this stale cache, causing it to:

  • Report “string not found” for text that IS in the current file

  • Show “fuzzy match” suggestions with content from the OLD branch

  • Make edits that corrupt the file by mixing branches

Workaround:

Use terminal commands (cat, grep, sed) directly instead of AI tools after git operations.

Impact:

High - can cause silent code corruption when AI edits files after branch switches.

Suggested Fix:

Invalidate the AI tool file cache when:

  • Git commands (checkout, switch, pull, merge, reset) are executed

  • File modification timestamps change

  • .git/HEAD or .git/index changes


Submit at: https://forum.cursor.com (Bug Reports category) or use Help → Report Issue in Cursor.

Well, ‘Help → Report Issue’ does not exist in my UI version. Included hereinabove. (And consider this comment as a bug report against your UI or what the tool knows about the IO when directing users)

Looking at the diff more carefully - it’s backwards:

-# - linear: K must be even (2 values per byte)

+# - ColumnMajor: K must be even (2 values per byte)

The committed version has linear (correct), but the working directory somehow reverted to ColumnMajor.

This is likely a Cursor tool cache issue - when I read the file earlier, stale content may have been written back. The committed version (in git) is correct.

Fix: Just discard the working directory changes:

git checkout pytorch/tests/test_gemm.py

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.