Cursor generates a clean diff, you hit Apply (the button in the chat panel, or you accept the staged change), the spinner runs for a second, and then nothing happens. The file doesn’t change, sometimes you get The apply model made no changes to the file, and the agent’s status doesn’t update. This isn’t a normal crash. Cursor’s apply step runs the diff through a separate “apply model” (it reconciles the suggested change against the file on disk; it is not a literal patch), so anything that blocks the write or desyncs the file causes a silent skip.
Fastest fix (clears most cases): save every open file with cmd-shift-s / ctrl-shift-s, close any other VS Code, Cursor, or editor window that has the same project open, then click Reapply in the chat or press cmd-enter / ctrl-enter. If the diff still shows as not applied, toggle Cursor Settings -> Agents -> Inline Diffs off and on, then retry.
This page breaks down the six root causes (highest hit-rate first), how to confirm which one you’re in, and the exact recovery for each. Tested against Cursor 3.7 (June 2026).
Which bucket are you in?
| Symptom you see | Most likely cause | Jump to |
|---|---|---|
| Apply button greys for a second, springs back, no change | Wrong edit surface / detached buffer | Cause 1 |
The apply model made no changes to the file | File desync or locked write | Cause 2 / Cause 5 |
| Works for small files, fails on big ones (“file too large”) | Oversized file or huge diff | Cause 6 |
| Diff never disappears after Apply | Base diverged since generation | Cause 5 |
| Edits apply with no Accept/Reject diff, or none apply at all | Inline-Diffs setting regression | Cause 1 |
401 / 403 / timeout in the network tab | Out-of-date client or model outage | Cause 3 |
Even touch on the file fails | Read-only filesystem / permissions | Cause 4 |
Common causes
1. Wrong edit surface, or the Inline-Diffs setting got knocked out
Cursor (3.x) has several edit surfaces: Chat / Ask (cmd-l) answers without writing, Inline (cmd-k) edits at the cursor, and Composer / Agent (cmd-i) edits across files and is the default surface in Cursor 2.x and 3.x. If you click Apply from an Ask/Chat answer while the target file isn’t the active editor, the apply often skips silently because it is reconciling against a detached buffer.
A second, newer variant (a regression that surfaced in early 2026): edits either apply with no Accept/Reject diff at all, or none apply. That is the Inline Diffs toggle, not a true apply failure.
Symptom: Chat shows the full diff, you press Apply, the button greys for a
second then springs back, no change made
Cause: apply reconciled against a detached file buffer, or Inline Diffs is offHow to spot it: switch to Composer/Agent (cmd-i) and re-run the prompt. If it applies there, you were in the wrong surface. If diffs aren’t showing an Accept/Reject control at all, open Cursor Settings -> Agents -> Inline Diffs and toggle it off then on.
2. File is locked by another process or git
.git/index.lock, .git/HEAD.lock, an active next dev / vite file watcher, or another VS Code / Cursor window with the same file open can all hold the write. Cursor does not pop a “locked” dialog; it returns The apply model made no changes to the file or just does nothing.
How to spot it:
ls -la .git/*.lock # stale lock files
lsof | grep <filename> # who has the file open (macOS/Linux)A stale lock, or another process holding the file, is this cause.
3. Cursor client is out of date, or the model endpoint is degraded
Cursor ships fast (roughly weekly; current build is 3.7 as of June 2026). Old clients can have apply-protocol mismatches against newer models. The other half of this bucket is a server-side incident: Cursor’s Auto model router and the upstream Anthropic models have had short degradations (for example, on June 16 2026 the status page logged elevated errors across Anthropic models and an Auto-model degradation, both since resolved). When the apply endpoint is degraded, apply quietly no-ops.
How to spot it:
Cursor -> About(orHelp -> About): is your version more than ~2 weeks behind?Cursor Settings -> Models: switch to a different model (or off Auto to a pinned one) and retry. Instant success on another model points at an endpoint issue.- Developer tools (
cmd-shift-p->Developer: Toggle Developer Tools): does the Network tab show401/403/ timeout? - Check status.cursor.com for an open incident.
4. Filesystem is read-only or write permission is denied
WSL across drives (/mnt/c/...), a Docker container with a read-only volume mount, macOS Full Disk Access not granted to Cursor, or an NFS / SMB network drive can all deny the write.
How to spot it:
touch path/to/the-file-you-want-to-edit # can you write at all?
ls -l path/to/the-file # permission bits
stat -f %Sp path/to/the-file # macOS permission stringIf even touch fails, it is a filesystem-layer issue, not a Cursor bug.
5. The diff base diverged from disk (“file changed since”)
If you manually edited the file (or a formatter ran) between Cursor generating the diff and you hitting Apply, the base mismatch causes a silent skip or The apply model made no changes to the file. Common triggers: prettier --write or another format-on-save, git pull, or the agent re-generating in the background.
How to spot it: Cursor’s status shows the file as modified, or after Apply the diff still shows in full instead of collapsing to “applied.”
6. File is too large, or the diff is huge
Cursor’s apply model has practical size limits. Very large files or sweeping multi-hundred-line diffs can trip a file too large style refusal or a silent no-op, even when the same prompt works on a smaller file. This became more common with the agentic multi-file flow in Cursor 2.x and 3.x.
How to spot it: the same prompt applies fine on a small file but fails on the big one, or the agent suggests recreating the whole file instead of editing in place.
Shortest path to fix
Ordered by time spent. Steps 1 and 2 clear most “Apply does nothing” cases.
Step 1: Save all open files, then close other editor windows
cmd-shift-s / ctrl-shift-s Save All (File -> Save All)
Then close any OTHER VS Code / Cursor / Sublime window with this project openCross-tool concurrent editing is the top trigger. After closing, return to Cursor and press cmd-enter / ctrl-enter, or click Reapply.
Step 2: Switch edit surface and re-run, or reset Inline Diffs
If Apply failed from Ask/Chat:
- Open Composer/Agent with
cmd-i. - Re-run the prompt and let it regenerate the diff.
- Composer/Agent stages each file as a reviewable diff with per-file Accept / Reject before writing, which is a more reliable apply path than Ask/Chat.
Or use cmd-k (Inline) directly in the file, select the block to replace, and edit in place. Inline beats Composer beats Ask/Chat for apply success rate, because smaller scope means fewer ways to fail.
If no Accept/Reject diff appears at all, reset it: Cursor Settings -> Agents -> Inline Diffs, toggle off and on, then retry.
Step 3: Clear git locks and stuck file watchers
# Clear git locks
rm -f .git/index.lock .git/HEAD.lock
# Find who is holding the file
lsof | grep src/components/UserSettings.tsx
# Kill the holder
kill -9 <pid>
# Restart the dev server (a stuck watcher blocks writes)
pkill -f "next dev"
pkill -f "vite"Then click Retry / Reapply in the chat panel, or hit cmd-enter / ctrl-enter.
Step 4: Update Cursor and try a different model
1. Cursor -> Check for Updates -> restart (target 3.7+ as of June 2026)
2. Cursor Settings -> Models -> switch the model
(e.g. Auto -> a pinned Sonnet 4.6, or Sonnet 4.6 <-> Opus 4.7,
or try Composer 2.5)
3. Re-run the prompt, then ApplyIf a pinned model succeeds instantly while Auto failed, the router or the original model’s endpoint is having issues. Confirm at status.cursor.com.
Step 5: Check filesystem permissions and open the project from a 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 filesystemCursor will not say “permission denied” on a read-only mount; it just silently skips.
Step 6: Shrink the edit, or hand-apply as a last resort
If the file is large or the diff is sweeping:
- Ask the agent for a smaller, scoped change (one function or one region at a time).
- If it still refuses, select the diff in chat,
cmd-c, open the target file, and apply the change by hand. - Verify with
git diff.
Hand-applying is not elegant, but it unblocks you immediately.
How to confirm it’s fixed
- The chat diff collapses to an applied/accepted state instead of staying fully expanded.
- The editor tab shows the new content (and a modified dot if unsaved).
git diff path/to/fileshows the expected change.- Re-running a trivial prompt (for example, add a one-line comment) applies cleanly on the first try.
Prevention
- Don’t edit the same file in multiple tools at once; close other VS Code / Cursor windows.
- Keep Cursor on auto-update (
Cursor Settings -> General -> Update). - Add
.git/*.lockcleanup to your dev-start script. - Don’t put projects on WSL
/mnt/c/...or a network drive; use the native filesystem. - Very large files (more than ~2000 lines) fail apply more often; break edits into smaller Composer/Agent patches.
- In
Cursor Settings -> Beta, disable experimental features you don’t need; new features ship new bugs. - On macOS, grant Cursor Full Disk Access so the sandbox doesn’t block writes.
FAQ
Why does Cursor say “The apply model made no changes to the file”? The apply model reconciled the suggested diff against the file and found nothing to write, usually because the file changed since the diff was generated (Cause 5), the write is locked (Cause 2), or the file is too large (Cause 6). Re-run the prompt so the diff is rebuilt against the current file, then Reapply.
What is the “apply model” and why isn’t apply just a patch? Cursor generates the edit with the main model, then a separate, faster apply model merges that edit into your file. This handles fuzzy matches and partial edits, but it also means a server-side degradation of that apply path can make Apply silently no-op even when the diff looks perfect.
Apply works in Chat but the diff won’t stick. What’s different about Composer?
Composer/Agent (cmd-i) stages changes as per-file diffs with Accept / Reject before anything writes to disk, and it targets files explicitly rather than a possibly-detached Chat buffer. That makes its apply path more reliable. Inline (cmd-k) is even more reliable for a single block.
Edits suddenly apply with no Accept/Reject prompt. Is that a bug?
That is the Inline Diffs setting, not an apply failure. Toggle Cursor Settings -> Agents -> Inline Diffs off and on. If you want to always review before writing, keep Inline Diffs on and avoid auto-accept.
How do I know it’s a Cursor outage and not my setup?
Switch from Auto to a pinned model in Cursor Settings -> Models. If the pinned model applies instantly, the router or an upstream model is degraded. Confirm at status.cursor.com.