Cursor generates a clean diff, you hit Apply (cmd-enter or the button in the chat panel), the spinner runs for a second, and then… nothing happens. The file doesn’t change, there’s no error, and Composer’s status doesn’t update. This isn’t a hard failure — Cursor’s “apply” runs through a separate LLM call (it’s not a literal patch), so anything that blocks the write causes a silent skip. This page breaks down 5 common root causes and gives you the right recovery and re-apply path.
Common causes
Ordered by hit rate, highest first.
1. Composer / Inline / Chat mode doesn’t match the target
Cursor has three edit surfaces: Chat (cmd-L) suggests without writing, Inline (cmd-K) edits at the cursor, Composer (cmd-I) edits across files. If you click Apply in Chat but the target file isn’t open in the editor, the apply often silently fails.
Symptom: Chat shows the full diff, you press Apply, the button greys for a
second then springs back, no change made
Cause: Cursor tried to apply to a detached file bufferHow to spot it: switch to Composer (cmd-I) and re-paste the prompt. If Composer can apply, you were in the wrong mode.
2. File is locked by another process or git
.git/index.lock, .git/HEAD.lock, an active next dev / vite file watcher, another VS Code window with the same file open — any of these can hold the write lock. Cursor doesn’t pop a “locked” dialog; it just doesn’t write.
How to spot it:
ls -la .git/*.lock # stale lock files
lsof | grep <filename> # who has the file openStale lock or another process holding the file = this cause.
3. Cursor extension / model endpoint is out of date
Cursor ships fast (every 1-2 weeks). Old versions can have apply-protocol mismatches against newer models; or you switched models (e.g. sonnet-4.5 → opus-4.7) and the local cache didn’t refresh.
How to spot it:
Cursor → About: is the version > 3 weeks behind?Settings → Models: swap to a different model and try again — instant signal- Dev tools (cmd-shift-P → “Developer: Toggle Developer Tools”): does the network tab show 401 / 403 / timeout?
4. Filesystem read-only / permission denied
WSL across drives (/mnt/c/...), a Docker container with a read-only volume mount, macOS Full Disk Access not granted to Cursor, an NFS / SMB network drive — the apply can’t get write permission.
How to spot it:
touch the-file-you-want-to-edit # can you write at all?
ls -l # check permission bits
stat -f %Sp <file> # macOSIf even touch fails, it’s a filesystem layer issue.
5. Diff base diverges from disk (“file changed since”)
If you manually edited (or a formatter ran) between Cursor generating the diff and you hitting Apply, the base mismatch causes a silent skip. Common triggers: prettier --write, git pull, the AI re-generating in the background.
How to spot it: Cursor’s status bar shows “File modified,” or after Apply the diff still shows in full instead of disappearing.
Shortest path to fix
Ordered by time spent. Steps 1+2 clear 70% of “Apply does nothing” cases.
Step 1: Save all open files + close other editor instances
Easiest win:
cmd-shift-S Save All (Code → File → Save All)
Then close any other VS Code / Cursor / Sublime window that has this project openCross-tool concurrent editing is the #1 trigger. After closing, return to Cursor and press cmd-enter to reapply.
Step 2: Swap between Composer / Inline / Chat, then reapply
If Apply failed in Chat:
- Select the full diff or answer in Chat
- cmd-shift-I to open Composer
- Paste the prompt and let it regenerate
- Composer’s apply takes a different path and often succeeds
Or use cmd-K (Inline) directly in the file, select the code block to replace, and have it edit in place. Inline beats Composer beats Chat for apply success rate (smaller scope = fewer ways to fail).
Step 3: Clear git locks and file watchers
# Clear git locks
rm -f .git/index.lock .git/HEAD.lock
# Find who's holding the file
lsof | grep src/components/UserSettings.tsx
# Kill the holder
kill -9 <pid>
# Restart dev server (stuck watchers block writes)
pkill -f "next dev"
pkill -f "vite"Then click “Retry” in the chat panel or hit cmd-enter to reapply.
Step 4: Upgrade Cursor + try a different model
1. Cursor → Check for Updates → restart
2. Settings → Models → switch the default model (e.g. sonnet-4.5 ↔ opus-4.7)
3. Have it regenerate, then ApplyIf a different model succeeds instantly, the original model’s apply endpoint may be having issues — check status.cursor.com.
Step 5: Filesystem permission check + open project from native path
# Can you write at all?
touch /path/to/project/src/file.tsx && echo OK || echo "no write permission"
# macOS: System Settings → Privacy & Security → Full Disk Access → enable Cursor
# Linux / WSL:
chmod -R u+w /path/to/project
# Avoid /mnt/c/... — move the project to ~/projects/ on the native FSCursor won’t say “permission denied” on a read-only mount; it just silently skips.
Step 6: Hand-apply as last resort
When everything else fails:
- Select the diff in Cursor chat, cmd-C
- Open the target file and apply the diff by hand
- Verify with
git diff
Not elegant, but it unblocks you immediately.
Prevention
- Don’t edit the same file in multiple tools simultaneously (close other VS Code / Cursor windows)
- Keep Cursor on auto-update (Settings → Update → Auto)
- Add
.git/*.lockcleanup to your dev-start script - Don’t put projects on WSL
/mnt/c/...or a network drive; use native filesystem - Very large files (> 2000 lines) fail apply more often — break edits into smaller Composer patches
- In Settings → Beta, disable experimental features you don’t need; new features have new bugs
- On macOS, grant Cursor Full Disk Access so the sandbox doesn’t block writes