I’ve been using VS Code workspaces at work to bring multiple existing repositories together, and honestly, it’s been awesome. It’s one of those features that’s been around for a while, but it becomes especially useful when you start working with AI coding assistants like Claude.

The problem I’m trying to solve is pretty common: I have a UI in one repository, an API in another, and sometimes a few other services or tools that all work together. I want to work across all of them without moving everything into a monorepo.

And I want Claude to have the same bigger-picture view that I do.

One workspace, multiple repositories

VS Code has a feature called a multi-root workspace. Instead of opening just one folder, you can add several folders to the same VS Code window and save the setup as a .code-workspace file.

For example, my directory structure might look like this:

development/
├── my-project.code-workspace
├── ui/          # its own Git repository
├── api/         # its own Git repository
└── shared-lib/  # another Git repository

And the workspace file can be surprisingly simple:

{
  "folders": [
    { "name": "UI", "path": "ui" },
    { "name": "API", "path": "api" },
    { "name": "Shared Library", "path": "shared-lib" }
  ],
  "settings": {}
}

Open my-project.code-workspace in VS Code, and all three projects show up in the Explorer.

The best part? Nothing about your Git repositories has to change. Each repository keeps its own history, branches, pull requests, permissions, and deployment pipeline. VS Code is simply giving you one place to work with them.

That’s exactly what I want. I don’t need to restructure our source control just to make day-to-day development easier.

Why this is especially useful for API + UI development

Say I’m building a feature that needs changes to both the frontend and backend.

Normally, I might have two VS Code windows open, bounce between them, and constantly explain how the API response maps to the UI. With a multi-root workspace, both codebases are in the same window.

I can search across the workspace, navigate between projects, and see each repository in Source Control. It’s still two separate repositories; it just feels like one connected development environment.

One of my favorite little things is Ctrl+P (Cmd+P on Mac). VS Code’s Quick Open lets me type a filename and jump straight to it, whether it’s in the UI or API repository. I don’t have to think about which VS Code window has the file open. I can pull up a frontend component, then jump right to the backend endpoint or service that supports it. And if I want to see both at once, I can open them side by side in split editors.

It’s a tiny workflow improvement that adds up throughout the day. Instead of treating the frontend and backend as disconnected projects, I get to work on the whole feature in one place. More context for me, more context for teammates, and—when configured to access the right folders—more context for Claude.

That alone is a nice productivity improvement. But adding Claude is where things get really interesting.

VS Code workspaces vs. Claude’s own project context

Claude has its own ways of organizing context. For example, Claude Projects can hold project-level instructions and reference material, while Claude Code can work with files in your development environment.

Those are useful, but they’re not quite the same thing as a VS Code multi-root workspace:

	VS Code multi-root workspace	Claude project / Claude Code context
Main purpose	Organize multiple local folders in one editor	Give Claude instructions, context, and access to relevant code or tools
Multiple repositories	Yes, as separate folders	Depends on which Claude product and how access is configured
Git boundaries	Each repository stays independent	Doesn’t change repository boundaries
Sharing	Commit a .code-workspace file	Share supported project instructions or commit CLAUDE.md files
MCP integrations	Configured through compatible tools/extensions	Claude Code can use configured MCP servers

They’re complementary, not competing features. A VS Code workspace tells my editor which folders belong together. Claude’s instructions and tooling help the assistant understand how to work across them.

One important detail: opening folders in a VS Code workspace does not automatically guarantee Claude can read all of them. That depends on the Claude integration you’re using and its file-access configuration. I always verify the assistant can actually see the folders I expect.

Taking it further with Claude files and MCP

What I’m working toward is a single development setup that brings together more than just source code:

• The UI and API repositories
• Shared libraries or related services
• Claude instructions about how the pieces fit together
• MCP integrations, including tools like Figma

Imagine asking Claude to look at a Figma design, inspect the existing UI components, and understand the API contract—all as part of the same workflow. That’s the direction I’m excited about.

I also like keeping reusable instructions in version control. A CLAUDE.md file can explain architecture, conventions, commands, and how the different services relate. Claude Code can use these files as project guidance.

For a team, that means the useful context doesn’t have to live only in one developer’s head or one person’s chat history.

You can review changes to the instructions through GitHub, improve them over time, and share them with other developers.

A practical way to share the setup

One approach is to create a small, separate workspace configuration repository containing a .code-workspace file, documentation, and shared Claude configuration.

For example:

team-workspace/
├── project.code-workspace
├── CLAUDE.md
└── README.md

That repository can describe which other repositories to clone and where to put them. The workspace file then points at those local folders using relative paths.

The important distinction is that the workspace file references the repositories; it doesn’t clone them for you. A teammate still needs to check out the repositories in the expected locations (or adjust the paths).

Likewise, a top-level CLAUDE.md is only useful if your Claude setup actually loads it. With Claude Code, instruction discovery depends on the working directory and project configuration, so it’s worth testing instead of assuming every file in the VS Code workspace is automatically included. Repository-specific CLAUDE.md files can live in their respective repositories as well.

For MCP, share safe configuration where your tools support it, but keep API keys, tokens, and other secrets out of Git. Each teammate should authenticate using their own credentials and have access only to the repositories and services they need.

This isn’t a monorepo, and that’s the point

I’m not against monorepos. They make sense for plenty of teams.

But sometimes your repositories are separate for good reasons: independent deployment, ownership, access controls, or simply because that’s how the systems have evolved.

A multi-root workspace gives you a unified working experience without requiring a unified repository.

You get the convenience of working across the whole feature while keeping the existing architecture and Git workflows intact.

My takeaway

I’ve been using this approach successfully at work, and it’s quickly becoming one of my favorite ways to organize development.

VS Code workspaces are already useful on their own. Pair them with Claude, version-controlled instructions, and MCP tools, and they start to feel like a lightweight hub for your entire development workflow.

I’m still experimenting with how much I can bring into one setup—especially things like Figma MCP—but I love the idea that a teammate could clone a small workspace configuration repository, open one file, and have a shared starting point for working across all the services.

One workspace. Multiple repositories. No monorepo migration required.

If you haven’t tried VS Code’s multi-root workspaces yet, give them a shot.

VS Code multi-root workspace documentation · Claude Code memory and instructions · Model Context Protocol