Your cursor worktree layout was supposed to keep branches separate, then Agent committed changes in the sibling folder you never opened.
You use git worktrees or keep two clones: one for production hotfixes, one for experiments. Cursor shows the correct file in the editor. You ask Agent to fix auth. The diff lands in the other checkout. You merge nothing useful. Usage still drops. Tests in the folder you actually run still fail. This is not random sloppiness. It is workspace root confusion plus search across duplicate paths.
The problem shows up often after exporting from Lovable or Bolt into a fresh directory while the old export stays on disk. Both trees look identical in chat. Agent picks the one its tools touched first. Fix the root and naming before you burn another hour of cursor usage limit on patches that never hit your running app.
Agent edits the wrong folder
This is the headline failure mode. You recognize it by path, not by error message.
- Diff paths start with a folder name you did not open in this window
- Git status in your terminal stays clean while Agent claims it fixed the bug
- You find the same change in
../app-copyorproject-worktree-2 - Search-and-replace hit both trees because both sit under one parent workspace
- Rules referenced
src/without saying which repo root - Production deploy pulls from repo A; Agent edited repo B
Worktrees share history but have separate working directories. Opening the parent directory that contains two worktrees gives Cursor visibility into both. Agent context may include files from either. Your eyes track the tab in front of you. The model tracks whatever path matched last.
Symptoms feel like “Agent ignored me.” Often it obeyed a path you did not mean. Narrow the workspace root and name the folder explicitly in every prompt until the behavior stabilizes.
Why cursor worktree layouts confuse Agent
Git worktrees exist so you can check out two branches without stashing. Cursor treats each folder as part of the workspace if you opened the parent. Indexing spans both. @ mentions search both. A prompt that says “fix login” without a root sends the model hunting across duplicates.
AI-generated apps make it worse. You clone my-saas from GitHub, then export again from Lovable into my-saas-lovable. Same components, different folders. Agent fixes Tailwind in the export while you run dev server in the clone. Both have src/pages/Login.tsx. Only one is wired to your Supabase project on the live URL.
Composer multi-file edits amplify damage. One wrong root means five wrong files. You revert or manually copy hunks. Each attempt billed against the same pool. Parallel product work on Lovable preview plus Cursor on the exported repo doubles the risk if folder names are vague.
Duplicate repos on disk
Even without git worktrees, duplicates cause the same bug.
- Old zip on Downloads still indexed because you opened it once
-mainsuffix folder next to the real repo after a bad extract- Monorepo sibling with identical package names
- Docker bind mount pointing at a different host path than Cursor
- Two windows open on different folders — Agent session tied to the wrong one
Audit before the next Agent run:
- Run
pwdin the integrated terminal and match it to the window title path - Close workspaces you are not actively editing
- Remove duplicate exports from the parent folder or exclude them in
.cursorignore - Rename folders with role labels:
saas-prod-clone,saas-experiment-wt
Fix cursor worktree before the next Agent prompt
Work in this order.
- Open only the target folder — File → Open Folder on the worktree root, not the parent containing three clones.
- Verify terminal cwd matches that root before asking Agent to run commands.
- Add a Rule with the absolute path: “Only edit files under
/path/to/correct-worktree.” - Name the folder in the prompt: “In
saas-prod-clone, fix …” - Reject diffs whose paths do not start with that root.
- One window per worktree during Agent sessions; close others.
- Align deploy path — confirm Vercel or hosting pulls the same folder you edit. See lovable deploy for publish wiring.
After a wrong-folder incident, diff the accidental tree against your real tree before deleting anything. Copy hunks manually once, then delete or ignore the stray copy so indexing stops crossing streams.
Pre-flight checklist
- Workspace root is the worktree you run locally, not a parent of several clones
- Terminal
pwdmatches workspace root - Cursor Rules state the allowed path prefix
- Prompts name the folder when duplicates exist
- Old exports excluded via
.cursorignoreor moved outside the repo parent - Diff review rejects paths outside the intended root
- Hosting deploys from the same tree you edit in Cursor
Agent fixes the paths it can see. Make sure it only sees one production tree.
FAQ
Why does cursor worktree make Agent edit the wrong folder?
Multiple checkouts of the same repo, git worktrees, or a parent folder opened as workspace root confuse context. Agent reads files from whichever path matches the prompt or search, not necessarily the tab you are viewing.
How do I set up cursor worktree so Agent stays in one repo?
Open the specific worktree folder as the workspace root, not the parent containing several clones. Put the absolute path in Cursor Rules and reject diffs outside that root during review.
Can cursor worktree waste credits like usage limit loops?
Yes. Wrong-folder edits do not fix your app but still burn tokens on large diffs. You revert manually while the meter drops — same pool as other Agent runs.