On October 28, 2026, GitHub put Copilot Projects into public preview in the GitHub Copilot app. A project gives work that spans several repositories, or needs no repository at all, one home for its context, its agents, and its results (GitHub changelog, retrieved October 31, 2026). You describe a goal and attach the material Copilot needs. You choose the models and tools for the job. Copilot then runs as many agents as the work needs in the background. It brings back results, such as pull requests, for your review.
Key Takeaways
GitHub released Copilot Projects in public preview in the GitHub Copilot app on October 28, 2026. The same release added Slack and Figma context and a computer use preview for macOS and Windows.
A project starts with a goal, not a repository. You add repositories, design mocks, Slack threads, or meeting notes as context. Copilot coordinates parallel agent sessions toward that goal.
A Library tab holds supporting files and artifacts the agents create. An Overview tab groups work by status: Needs input, Open, Working, and Done.
Project automations handle repeatable tasks. For example, a project can create a promo video whenever a feature lands. You can pause, reschedule, or delete an automation.
Computer use lets Copilot read app content, click controls, enter or edit text, and move across desktop apps. This includes apps with no API, command line interface, or MCP integration. It asks for approval before controlling an app, and an organization can disable it.
The timing matters. Copilot began as an assistant inside an editor. It answered questions about the file in front of you. Projects moves the unit of work up one level. It goes from a single session about a single repository to an ongoing goal. That goal can touch several repositories and several kinds of material. The question to judge is new. It is not whether Copilot can write a function. It is whether it can keep a multi part job organized while a human stays in charge of the decisions.
What Is GitHub Copilot Projects?
GitHub Copilot Projects is a workspace in the GitHub Copilot app. It gives Copilot an ongoing goal. It lets Copilot coordinate work across repositories, sessions, and recurring tasks. That is how GitHub's projects documentation describes it. The definition carries two important limits. First, a project is organized around a goal, not around a codebase. Second, Copilot coordinates the work, but results still come back to you for review. A pull request is an output to inspect. It is not a decision already made.
Starting a project follows a simple pattern. In the sidebar of the Copilot app, you create a project. You describe what you want to get done, including the results you want and any constraints. You can add repositories, or start with none at all. GitHub's documentation gives a concrete example. Investigate customer feedback about a new search feature. Group it by theme. Suggest what to improve. Use only the feedback document provided. Make no code changes (GitHub documentation, retrieved October 31, 2026). That example is useful. It shows a project doing non coding work: reading, grouping, and recommending. It also shows an explicit boundary on what Copilot may not touch.
Overview is the board where you follow a project. Once work is running, you follow it in the project rather than directing each session separately. The Overview tab groups work by status. Needs input collects decisions, reviews, and permission requests that need your attention. Open shows work with an open pull request, including the lines added and deleted. Working shows sessions currently running. Done shows completed work. To inspect one session, you open it and review its conversation, changes, pull request, and plan. You can also send a message in Steer this session to give further direction.
Capability | Status | What it changes |
|---|---|---|
Copilot Projects | Public preview | One workspace for a goal across repositories, with parallel agents and pull requests as output |
Slack and Figma context | Available in the Copilot app | Product and design context for research, specifications, and design work alongside code |
Image generation and editing | Available in chat | Images made and edited from natural language prompts inside the app |
Computer use | Public preview on macOS and Windows | Copilot drives desktop apps that have no API, command line interface, or MCP integration |
Project automations | Available in projects | Repeatable tasks on a schedule, with pause, edit, and delete controls |
How a Project Runs, Step by Step
The documentation breaks a project into four parts. Each part answers a different question about control:
Goal. You state what you want and what counts as a result. You add constraints, such as using only the provided material or making no code changes.
Context. You attach repositories and supporting material. The Library tab holds files you add and artifacts agents create. Reference material and results live in the same place.
Sessions. Copilot runs as many agents as the work needs, in parallel, managed sessions. You track them in Overview. You steer individual sessions when they drift.
Automations. You describe a recurring task and its schedule in the project conversation. Then you check, pause, edit, or delete it from the Automations tab.
The Library deserves attention. It is where a project can quietly go wrong. GitHub advises keeping material relevant to the project goal. It also advises telling Copilot which sources to use when assigning a task. Follow that advice literally. A project that can see everything will eventually use the wrong document. A project with a tight, relevant library gives you a clear answer when you ask why it did what it did.
Automations work the same way. GitHub's example is a weekly summary. Every Monday at 9 AM, review the customer feedback in the project library. Group it by theme. Include supporting examples. Raise questions to investigate. The schedule is visible in the Automations tab. You can change it by asking in the project conversation or editing it by hand. A recurring agent task is only safe if its schedule and its scope are both easy to inspect. Projects makes both visible.
Projects Versus a Single Repository Session
For a focused task in a single repository, GitHub still recommends starting a session directly from that repository. Use a project when you want Copilot to coordinate work toward a broader goal (GitHub changelog). That distinction is the practical rule for choosing between the two. A single session is a conversation about one job. A project is a container for many jobs that share a goal, a library, and a review surface.
The difference also shows up in how you spend your attention. In a session, you watch one agent work. In a project, you watch a board. You see which items need your input, which have pull requests open, which are still working, and which are done. That board is the real product here. Parallel agents without a review surface would just be more output to chase. The Overview statuses turn that output into a queue you can work through.
Slack, Figma, and Images in the Same App
The same October 28 changelog entry adds context from connected tools such as Slack and Figma. You can use that context to research a request, draft a specification, or work through a design alongside your code (GitHub changelog). The point is not the connectors themselves. It is that a project goal often lives outside code. It may be a decision in a Slack thread, a design in Figma, or a note from a design meeting. If Copilot can only see repositories, those inputs have to be copied by hand. The copy is where context gets lost.
The entry also adds image generation and editing from natural language in chat. GitHub's example is a promo video created by a project automation whenever a feature lands. That shows how the pieces combine. A project notices a shipped feature, and an automation produces the announcement asset. Treat generated images the same way you treat generated code. They are drafts to review, not finished assets. That matters most where a brand or a license is involved.
Computer Use: Copilot Outside the Editor
Computer use is the Copilot app feature that lets Copilot work through tasks in desktop apps. It reads what is on screen and operates the interface. In the October 28 entry it is in public preview on macOS and Windows. Copilot can read app content, click controls, enter or edit text, and navigate across apps. This includes apps without an API, command line interface, or MCP integration (GitHub changelog). GitHub's example is an expense report workflow. That is the kind of job that lives in a closed business app no one built an integration for.
The controls around it are explicit, and they should shape how you try it. Copilot asks for your approval before controlling an app. Your organization can disable the feature through managed settings. To turn it on, open Settings, then Computer Use, and select Enable Computer Use. On macOS, you must also grant Accessibility and Screen Recording permissions. Those permissions are the honest price of the feature. To drive an app, Copilot must be able to see its screen and operate its controls.
Independent coverage draws the same line, with a warning attached. Mail Studio notes that computer use grants an agent user like access to third party applications. Sometimes it leaves no audit trail like an API call would. Mail Studio recommends keeping the feature off by default through managed settings. It also recommends limiting it to pilot accounts on dedicated machines (Mail Studio, retrieved October 31, 2026). That advice is sound. Start computer use on a machine that holds nothing sensitive. Use an app whose mistakes are cheap. Review every action until you trust its judgment on that specific workflow.
What Is Still Unclear
Projects is a public preview, and GitHub's documentation says so plainly. The feature is subject to change. Menus, behavior, and limits may move before general availability. Treat any workflow you build on it as something you may need to rebuild. The changelog also does not say which Copilot plans include Projects. It does not describe how Projects usage is metered. Independent coverage flags that gap directly (LetsDataScience, retrieved October 31, 2026). Until GitHub publishes those terms, do not budget a team rollout around assumed pricing.
A second open question is quality at scale. Parallel agents produce parallel output. The Overview board only helps if someone actually works the queue. Needs input items are decisions, not notifications to clear. A team that starts five projects and reviews none of them has not automated its work. It has created five backlogs. The discipline Projects demands is the same discipline code review already demands. Every pull request gets read before it merges, no matter which agent wrote it.
Who Should Try Projects, and Who Should Wait
Try Projects if your work already spans repositories or mixes code with documents. A feature launch that touches an API, a client, and a docs site is a natural first project. A weekly feedback review, with a tight library and a visible automation schedule, is another. Both give Copilot a goal you can state, material you can bound, and results you can review.
Wait if you need stable behavior, published plan terms, or a clean audit trail for every action. Computer use in particular is a pilot feature, not a production automation layer. Limit it to non critical apps. Keep it disabled by organization policy until you have a reason to enable it. Never let it touch credentials, payments, or personal data on its first runs. The same caution applies to any automation that can create pull requests on a schedule. Check its first runs by hand before you trust its tenth.
Frequently Asked Questions
What is GitHub Copilot Projects? It is a workspace in the GitHub Copilot app, in public preview since October 28, 2026. It gives Copilot an ongoing goal. It lets Copilot coordinate work across repositories, sessions, and recurring tasks. You describe the goal, add context, and review results such as pull requests.
Do I need a repository to start a project? No. A project can span one or more repositories. It can also focus on tasks that need no repository at all. Examples include investigating customer feedback or drafting a specification from documents in the project library.
How do I follow what agents are doing in a project? Use the Overview tab. It groups work into Needs input, for decisions and permission requests; Open, for work with an open pull request; Working, for sessions currently running; and Done, for completed work. Open a session to review its conversation, changes, pull request, and plan.
What is computer use, and is it safe to enable? Computer use lets Copilot read app content, click controls, enter or edit text, and navigate across desktop apps on macOS and Windows. This includes apps with no API or MCP integration. It asks for approval before controlling an app, and an organization can disable it. Start on a dedicated machine with non critical apps, and review every action before wider use.
Which Copilot plan includes Projects, and how is it billed? GitHub has not stated that in the October 28 changelog entry. Independent coverage notes the same gap. Do not assume a plan or a price until GitHub publishes Projects plan and metering terms.
Our methodology for this article was to compare the GitHub changelog entry and the projects documentation, both retrieved October 31, 2026, with independent coverage from Mail Studio and LetsDataScience. Where GitHub had not published plan or metering terms, we flagged that gap as unconfirmed instead of filling it in.
The Bottom Line
Copilot Projects is GitHub moving the agent conversation from one repository to one goal. The workspace, the library, and the Overview board are the parts that matter most. They let a human supervise several agents without losing track of what each one did. Computer use is the riskier half of the same release. It is genuinely useful for closed business apps. It also genuinely demands approval controls, dedicated machines, and review. Start with a small, well bounded project. Work its Needs input queue by hand. Let the automation earn a wider scope. Read the GitHub changelog entry and the projects documentation, or read the Indonesian version of this article. For the agent coordination angle, see our Routa article and our Microsoft Scope article.