GitHub Copilot Spaces: Persistent Context Beyond the Repository¶
What Are Copilot Spaces?¶
Copilot Spaces are persistent, shareable containers for the context that GitHub Copilot uses to ground its responses. Where repository-level customization files (.github/prompts/, .github/instructions/, .github/agents/) live inside a codebase and are versioned with code, Spaces operate at the GitHub platform level — independent of any single repository, persistent across sessions, and shareable with individuals or teams.
The core problem Spaces address is context that doesn't belong in a repository but still needs to inform Copilot's answers: cross-project architectural decisions, sprint plans and meeting transcripts, onboarding documentation, design references, and uploaded documents. Without Spaces, this context either has to be pasted manually into each conversation or stored in a repository where it doesn't conceptually belong.
Spaces became generally available in May 2026. The Spaces API reached general availability on May 18, 2026.
What a Space Contains¶
A Space has two types of content:
Instructions — Free-text guidance that tells Copilot what to focus on within the Space, analogous to a .instructions.md file at the Space level. Instructions are injected directly into Copilot's system prompt when a user chats in the Space — they are not indexed for semantic search.
Sources — Content that Copilot uses to ground its responses. Four types of sources can be added:
| Source type | What it provides | How Copilot uses it |
|---|---|---|
| Files and repositories | Code, docs, configs from GitHub repos | Searches semantically, or loads entire files into context |
| Links | URLs to pull requests, issues, other GitHub content | Fetches and references the linked content |
| Uploaded files | Local documents, images, spreadsheets | Loads into context window |
| Text content | Pasted notes, transcripts, free-form text | Loads into context window |
An important behavioral distinction: attaching a repository makes Copilot search it semantically — not everything is loaded at once, making it practical for large codebases. Attaching individual files loads their full contents into the context window for every query, making them consistently prioritized. GitHub-based sources (repositories, linked content) stay automatically synchronized as they change — the Space reflects the current state of the main branch without manual refresh.
How Spaces Complement the Copilot Customization Stack¶
Spaces occupy a distinct layer in the GitHub Copilot customization model:
| Mechanism | Scope | Lives in | Persistence | Best for |
|---|---|---|---|---|
Prompt files (.prompt.md) |
Project | Repository | Versioned with code | Reusable task templates |
Instruction files (.instructions.md) |
Project or path | Repository | Versioned with code | Coding standards, project rules |
Agent files (.agent.md) |
Project | Repository | Versioned with code | Specialized assistant roles |
| MCP servers | Project or global | Config files | Session-based | External tool access |
| Copilot Spaces | Cross-project | GitHub platform | Persistent, shareable | Curated knowledge bases, onboarding, ephemeral context |
Repository-level files are developer-authored, code-adjacent, and versioned. Spaces are curator-managed, platform-level, and independent of any single codebase. This means teams can build and maintain Spaces as living knowledge resources without requiring contributors to understand or modify repository structure.
Sharing and Access Control¶
Spaces can belong to a personal account or to an organization, with different sharing models:
Organization-owned Spaces can be shared with organization members, with three access levels: admin, editor, and viewer. Alternatively, they can be kept hidden from organization members. This supports use cases like team onboarding kits, project knowledge bases, and documentation references that should be broadly accessible within a specific group.
Individual-owned Spaces can be shared publicly, shared with specific GitHub users, or kept private. Publicly shared Spaces are view-only; viewers can only see sources they have independent access to (so sharing a Space doesn't grant access to private repositories referenced within it).
Using Spaces in the IDE¶
Spaces are accessible in Copilot Chat in GitHub (github.com). They are also available in VS Code and other IDEs via the GitHub MCP server, which exposes Space context to the IDE agent. This means Space-grounded context can be used in editor-based coding sessions, not just in the GitHub web interface.
Spaces API: Programmatic Management¶
The Spaces API, which reached general availability on May 18, 2026, allows programmatic management of Spaces without relying on the GitHub UI. Operations supported:
- Create new Spaces
- Retrieve details about existing Spaces
- Update Space configurations
- Delete Spaces
- Manage collaborators and resources within Spaces
The API is particularly useful for enterprise teams managing multiple Spaces at scale — for example, automating the creation of onboarding Spaces for new projects, synchronizing Space content with external knowledge management systems, or enforcing governance policies across Space configurations.
Usage and Billing¶
Questions submitted in a Space count as standard Copilot Chat requests. For Copilot Free users, this counts toward the monthly chat limit. For premium model usage in a Space, requests count toward the premium usage quota with model multipliers applied. Spaces themselves do not have separate subscription costs — any user with a Copilot license (including Copilot Free) can create and use Spaces.
Key Use Cases¶
Spaces are most valuable when:
- Onboarding teams: a curated Space containing architecture docs, coding conventions, and common patterns gives new developers immediate Copilot-grounded context without requiring them to ask basic questions repeatedly.
- Cross-project knowledge: architectural decisions that span multiple repositories have no natural home in any single repo; a Space is the appropriate container.
- Ephemeral project context: sprint plans, meeting transcripts, and design documents that should inform Copilot answers during a sprint but don't belong in version control.
- External references: pull requests, issues, and uploaded specifications that should be consistently available to Copilot across a team's sessions.
Changelog¶
2026-05-20 — Page created from GitHub changelog (GA, May 18, 2026) and GitHub Docs (Type B ×2 official sources, confidence 75)