Cursor or Copilot Edits Wrong Folder in Multi-Root Game Repo - Rules and Workspace Scope Fix

When your workspace contains more than one project root (for example a Unity game, a shared tools repo, and a documentation site), coding assistants may apply changes under the wrong root. The symptom is subtle but expensive: files update without errors, builds still run in isolation, and you only notice after a merge or CI diff when assets land beside the wrong Assets tree or the wrong project.godot.

This article gives a practical containment path for Cursor, GitHub Copilot in VS Code, and similar VS Code-based assistants. The goal is not perfect AI behavior every time; it is to make wrong-root edits hard to do accidentally and easy to catch early.

Direct answer

Wrong-folder edits in multi-root setups happen when the assistant optimizes for the recently opened file, the shortest matching path, or the first workspace folder in the list—not the folder you meant. Fix it by (1) making one primary folder the edit target for each session, (2) adding repo-local rules that name allowed roots and banned roots, (3) prefixing requests with absolute or workspace-relative paths, and (4) running a two-file diff check (path + project marker file) before you trust a large refactor.

Who this affects

You are in the target audience if:

• your .code-workspace lists multiple folders (game + forked plugin + backend + docs)
• you see edits under OtherProject/Assets/... when you meant Game/Assets/...
• duplicate folder names exist (Assets, Packages, scripts) across roots
• Copilot or Cursor “fixes” a file that shares a name with another root’s file

Fastest relief is usually shrinking the session to one folder until the task is done.

Why this happens

Assistant tools infer context from:

• active editor and recently viewed files
• search results that match filenames across roots
• workspace ordering when two paths are equally plausible
• ambiguous prompts (“update the player script”) without a path

Multi-root workspaces are legitimate for real studios. They simply increase the chance that two roots look equally “correct” to automation.

Step 1 - Name workspace folders so roots are human-obvious

Open your .code-workspace file and give each root a distinct name that appears in the UI (not only the disk path).

Checklist:

1. Avoid duplicate labels such as two entries both named game or src.
2. Prefer names that encode purpose: unity-client, godot-prototype, shared-docs, backend-services.
3. Put the primary project you are editing today first in the folders array if your workflow allows it, so default search and quick-open bias toward that tree during the session.

This does not guarantee correct AI routing, but it reduces ambiguity for you and for tools that display folder names.

Step 2 - Make one root the session edit target

Before a large AI-assisted change:

1. Close editors from other roots unless you truly need them as reference.
2. Open at least one file from the correct root so the active context matches your intent.
3. State the root in your prompt: “Only edit files under unity-client/ for this task.”

If you skip this, large refactors are high risk even with good rules.

Step 3 - Add Cursor rules that forbid cross-root edits

If you use Cursor, keep project rules under .cursor/rules/ in the repo that should own the behavior (often your game repo root).

Your rules should include explicit constraints such as:

• which directories are in scope for gameplay code
• which directories are read-only references (plugins, submodules)
• a rule that new files must not be created outside the active game root without explicit instruction

Keep rules short and enforceable. Long essays get skipped under pressure; bullet rules survive.

If your game lives in a monorepo, scope rules per subtree rather than maintaining one giant global instruction file that contradicts itself.

Step 4 - GitHub Copilot users - narrow VS Code window scope

For Copilot Chat and inline edits in VS Code:

• Prefer opening the single-folder workspace for deep refactors.
• When you must stay multi-root, mention full paths in prompts and ask for a file list before applying patches.
• If your team uses instructions files supported by your Copilot setup, store them in the repo that should own behavior and reference paths there explicitly.

The principle matches Cursor: reduce parallel truths.

Step 5 - Add mechanical verification before you trust the result

After any AI-assisted batch edit:

1. Run git status from each root or from the monorepo root and confirm changed paths match the intended prefix.
2. Search for accidental duplicates: two modified files with the same relative suffix (Assets/Scripts/Player.cs) under different roots.
3. Open your game engine and confirm the edited asset appears in the expected project window.

If you use Unity, a wrong-root edit often still “looks fine” in isolation until meta files and GUID expectations diverge.

Alternative fixes for stubborn setups

• Submodule or git subtree layout: treat the consuming game root as the only writable tree during gameplay tasks; open that folder alone.
• Symlinked duplicates: eliminate duplicate paths assistants can confuse; symlink tricks are a frequent source of double matches.
• Generated folders: mark generated output directories as excluded from AI edits in your rules so assistants stop “fixing” build artifacts.

Prevention tips

• Keep a short runbook in your repo README: “How we open this repo in the IDE for gameplay work.”
• Standardize one command that opens the correct single-folder workspace for day-to-day engineering.
• When onboarding new contributors, show a bad example diff from a wrong-root edit so the failure mode is recognizable.

Related problems and links

• Wrong content pipeline after asset edits: verify you are not mixing Addressables or streaming assets across branches; see our Unity Addressables invalid key runtime asset loading fix if loads fail after path churn.
• Godot edits not reflected: confirm you edited the same folder Godot opened; see Godot 4.5 C# hot reload not working for project-folder alignment habits.
• Quest build-only interaction issues after “fixes”: validate device-target edits landed in the Unity project you actually ship; see Unity XR hands jitter or teleport in Quest build.

Official references:

• Visual Studio Code documentation on multi-root workspaces

Bookmark this page if you routinely keep multiple engines or forks in one IDE window.

Share it when someone asks why AI refactors “worked locally” but touched the wrong subtree.

FAQ

Should I stop using multi-root workspaces entirely?

Not necessarily. Multi-root is useful for tooling and docs. For high-risk refactors, temporarily switch to a single-folder window.

What prompt prefix works best?

A path prefix works best: “Under unity-client/Assets/... only, change …” Avoid vague nouns like “the scripts folder” when multiple roots have Scripts.

Does putting the game folder first always fix it?

It helps human workflow and some searches, but it is not a guarantee. Combine ordering with rules and verification.

What if both roots are Unity projects?

Treat that as maximum risk. Strongly prefer separate IDE windows, distinct workspace files, and explicit filename prefixes in prompts.

Is this a bug in Cursor or Copilot?

Usually it is ambiguous workspace context, not a single deterministic defect. Treat it as a workflow problem you control with scope discipline.