VS Code Workspaces for Multi-Repo Delivery

Many teams do not use a monorepo. The frontend lives in one repository, the backend in another, and every feature crosses both. VS Code multi-root workspaces give you a lightweight way to work across that boundary: one window, one search surface, one debug entry point, and one place to coordinate AI guidance. This edition explains what a workspace actually is, how to set one up for two repositories, and why that improves GitHub Copilot for end-to-end work.

What a VS Code Workspace Actually Is

In VS Code, the feature most people mean when they say "workspace" is a multi-root workspace: a saved <name>.code-workspace file that opens multiple folders in one window.

That is the useful step for GitHub Copilot. Instead of running one chat or agent session in the frontend repo and another in the backend repo, you can give Copilot one working surface that spans both.

A simple layout could look like this:

~/git-repositories/
  customer-portal.code-workspace
  customer-portal-web/
      .github/
      src/
  customer-portal-api/
      .github/
      src/
  billing-service/
  data-platform/
  internal-tools/

The point is not "open everything nearby." The point is "open the repos that ship the feature together."

The <name>.code-workspace file is just JSON. At minimum, it contains a folders array. It can also hold workspace settings, launch configurations, tasks, and extension recommendations.

{
   "folders": [
       {
           "name": "frontend",
           "path": "customer-portal-web"
       },
       {
           "name": "backend",
           "path": "customer-portal-api"
       }
   ],
   "settings": {
       "workbench.editor.labelFormat": "medium",
       "files.autoSave": "afterDelay"
   }
}

Why This Matters for Copilot

For separate frontend and backend repositories, the workspace becomes the place where Copilot can follow the whole feature instead of just one side of it.

• Search spans both roots, so Copilot can trace a field or endpoint across UI and API boundaries faster.
• Source Control shows multiple repositories in one session, which makes it easier to review the real scope of a change.
• Tabs and results stay labeled by folder, so duplicated filenames are less confusing.

You can also simplify the prompt itself. Without a shared workspace, the same feature often turns into two separate prompts because Copilot only sees one repo at a time.

Before:

Frontend repo prompt:

Add a Customer Number field to the customer create form. In CreateCustomerDto the field is named customerNumber.

Backend repo prompt:

Add customerNumber to CreateCustomerDto, the service, and the persistence model.

With a multi-root workspace, that can become one simpler prompt because Copilot can inspect both sides, find CreateCustomerDto, and reuse the same field name across frontend and backend.

After:

Workspace prompt:

Add a Customer Number field to the customer create form end to end.

That is not just shorter. As covered in CW10, premium cost is driven by how many prompts you send. Two separate repo prompts are two premium requests at the chosen model multiplier; one workspace prompt is one. Follow-up turns still cost extra, but the starting point is simpler and cheaper.

This is the practical benefit: you keep separate repositories, but you remove a lot of context switching.

Getting Started

If you have never used workspaces before, the simplest starting point is this:

1. Create a <name>.code-workspace file in a parent folder near both repositories.
2. Add the frontend and backend folders to the folders array and save the file.
3. Double click the workspace file or use the command code <name>.code-workspace to open it in VS Code.

If you prefer the UI flow, open one repo, add the second folder to the workspace, then save the untitled workspace as a .code-workspace file as described here.

The same file can also hold:

• settings for workspace-wide editor behavior
• launch for debug and start flows
• tasks for shell-based build, test, or start commands
• extensions for recommended extensions

More information about the file format can be found in the VS Code documentation.

Once that is in place, GitHub Copilot has a much easier time working end to end because the editor session already contains both halves of the feature.

Copilot Instructions in a Multi-Repo Workspace

In a multi-root workspace, VS Code does not treat the folder that stores the <name>.code-workspace file as a magical instruction root. It scans each workspace folder root for instruction files. In other words, if your workspace opens customer-portal-web/ and customer-portal-api/, Copilot can pick up:

• customer-portal-web/.github/copilot-instructions.md
• customer-portal-api/.github/copilot-instructions.md
• matching *.instructions.md files under each repo's .github/instructions/
• AGENTS.md files inside each repo, with the nearest file in the directory tree taking precedence

This is the important implication: yes, individual project instructions still apply in a multi-root workspace. They are discovered from the roots that are actually part of the workspace.

The reverse matters too: a .github/copilot-instructions.md next to the saved <name>.code-workspace file is not automatically picked up unless that parent directory is also added as a workspace root.

Pro Tips

• Give the roots explicit names like frontend and backend in the workspace file. That makes tabs, search results, and launch configurations much easier to scan.
• Put editor-wide preferences in workspace settings, not in folder settings. In multi-root mode, folder settings only apply to resource-specific behavior.
• Keep the workspace small. For this use case, frontend and backend are enough. Add more repos only when they are directly part of the same delivery flow.
• You can use compound launch configurations for the frontend and backend pair you actually ship together. That gives Copilot and the developer the same runtime entry point.
• Keep Copilot instructions inside the repo they describe. The saved <name>.code-workspace file is not a substitute for per-repo instruction files.