Back to Blog
tips

GitHub Copilot Workspace vs Codebase: Stop Confusing These Two

Most developers confuse #codebase and @workspace in GitHub Copilot. They are different tools for different situations. Here is exactly what each one does and when to use it.

Curious Adithya7 min read

Most developers using GitHub Copilot in VS Code are getting half the value out of it because they have never heard of workspace indexing. Or they have heard of it, used it once, and moved on without understanding what they were actually doing.

There are two ways to bring your entire project into a Copilot conversation: #codebase and @workspace. They look similar. They do very different things. Once you understand the difference, your Copilot conversations get dramatically more useful.

What Copilot Knows Without You Telling It Anything

By default, GitHub Copilot in VS Code sees whatever is in your active file. It sees the code around your cursor. If you open the chat sidebar, it sees the current file context.

That is actually quite limited for any real project. A modern codebase has hundreds or thousands of files spread across multiple folders. Copilot, out of the box, is working with a tiny slice of that.

Workspace indexing changes this. It lets Copilot build a picture of your entire project so that when you ask a question, it is not answering from one file. It is reasoning about your codebase as a whole.

The Index: What It Is and How to Build It

Copilot needs to index your workspace before it can reason about the full project. Think of this like building a search index. Without it, Copilot is reading in the dark.

You can check if your workspace is indexed by hovering over the GitHub Copilot icon in the VS Code status bar at the bottom. It will tell you whether indexing has happened or not.

If it has not, open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P) and search for workspace index. You will see two options:

  • Build Local Workspace Index - stores the index on your machine
  • Build Remote Workspace Index - stores the index in GitHub cloud

The local index works even if you have not pushed to GitHub yet. This is a detail that trips a lot of people up. You do not need a remote repository to get workspace indexing working. Build the local index and you are good.

For the remote index, you need to have a git repo initialized and pushed to GitHub. Once you do, GitHub will automatically start building and maintaining the index for you. As of 2025, semantic code search indexing completes in just a few seconds for most repositories, down from the five or so minutes it used to take.

What is #codebase

#codebase is a chat variable. When you include it in a Copilot chat message, you are telling Copilot to pull in context from your entire indexed codebase as part of that query.

The way it works under the hood: Copilot runs a search across your indexed files, finds the most relevant code snippets for your question, and includes those as context before generating its response.

You use #codebase when you want Copilot to find something across your project. Good examples:

  • What is my test coverage in #codebase?
  • Find all places in #codebase where I am making API calls without error handling
  • Does #codebase have any authentication middleware?

It is a context tool. You are pointing Copilot at the right material so it can give you an accurate answer.

What is @workspace

@workspace is a chat participant. This is a different concept. Chat participants are not just context identifiers. They are separate LLMs hosted by GitHub that have been given extra capabilities and reasoning layers on top of the base Copilot model.

The @workspace participant knows your codebase index AND has additional reasoning capabilities layered on top. It is smarter about your project. It can do more nuanced reasoning, make recommendations based on what it sees in your code, and give you more thoughtful responses.

When you type @workspace at the start of a message, your question goes to this specialized model instead of the default Copilot chat LLM. The response is typically more detailed and context-aware.

Good examples for @workspace:

  • @workspace what testing framework is in use here? If none, what would you recommend for this codebase?
  • @workspace explain the overall architecture of this project
  • @workspace where would I add a new API endpoint following the existing patterns?

The Practical Difference

Here is the mental model that makes this click:

#codebase tells Copilot to look at your code as a context source. It is like handing someone relevant files before asking a question. The response comes from the standard Copilot model.

@workspace hands your question to a specialized model that already has access to your codebase and brings additional reasoning to the table. The response comes from a more capable model focused on code intelligence.

For simple lookups (does X exist in my codebase, show me all files that use Y), #codebase is fast and effective.

For architecture questions, pattern analysis, recommendations, and anything where you want genuine reasoning about your project, @workspace gives you more.

You can see which model responded to your message by hovering over the response in the chat panel. It will tell you whether it came from the standard Copilot LLM or from the workspace chat participant. Knowing this matters because it tells you what level of reasoning was applied.

Getting the Most Out of Workspace Context

A few things that make workspace context more useful:

Index before you ask. Build the index when you start a new project or after pulling significant changes. Stale indexes give stale answers.

Use local index for private projects. You do not need to push to GitHub to get workspace indexing. Build local, get full context, keep your code private.

Combine context variables. You can use #codebase alongside other variables like #file if you want to emphasize a specific file while also pulling in broader context.

Ask specific questions. The more specific your question, the better Copilot can search the index for relevant material. Vague questions get vague answers whether or not you are using workspace context.

Know when to use neither. For questions about a specific function or block of code you are looking at right now, you do not need workspace context at all. Just ask. Copilot already sees what is on your screen.

Why This Matters More Than Most Copilot Tips

Most Copilot tips are about prompting tricks or tab completion shortcuts. Workspace indexing is different because it changes the fundamental scope of what Copilot can see.

Without indexing, every question you ask is answered with limited visibility. Copilot might know the file you have open but it has no idea how that file connects to the rest of your project.

With indexing and the right context variables, Copilot can reason about your entire project. It can spot patterns, find inconsistencies, suggest refactors that fit your existing conventions, and help you navigate a large codebase you might not know perfectly yourself.

For solo developers working on their own projects, the difference is noticeable. For developers joining an existing codebase they have not fully internalized yet, workspace indexing is genuinely transformational.

Key Takeaways

  • #codebase is a chat variable that adds your indexed codebase as context for the standard Copilot model. Best for lookups and specific searches.
  • @workspace is a chat participant with its own specialized LLM and additional reasoning. Best for architecture questions and nuanced analysis.
  • Build the index first. Check the status bar icon. Use the Command Palette to trigger it manually if needed.
  • Local index works without pushing to GitHub. Remote index requires a git repo pushed to GitHub.
  • Semantic indexing now completes in seconds for most repositories. It is fast enough to use regularly.
  • Hover over Copilot responses to see which model generated them. This tells you whether reasoning was applied.

Written by Curious Adithya for Art of Code.