Copilot Projects Enters Public Preview: One Job Across Many Repos, No More Three Sessions

At GitHub Universe on October 28, 2026, GitHub brought something new to the Copilot app: Copilot Projects, now in public preview. Let us define it clearly before the jargon piles up. Until now, using Copilot mostly meant one repository and one session: open a project, state a request, get back code or a pull request. Projects flips that around. The work itself is the main character. One project can span several repositories, or touch no repository at all — for example, a launch plan with specs, design assets, and to-dos — while Copilot coordinates multiple agents in the background and hands the results back to you for review. In short: before, you walked an agent into a repository; now you hand an agent a goal, and it connects everything relevant by itself.

One boundary first, to avoid confusion: this article is about Projects and the Copilot app itself, not the model-routing feature announced the same day. That is a different thing, with different billing and a different problem to solve, and its scores and prices should not be mixed into this story. Projects does not answer "which model is cheaper." It answers "what do you do when one job is scattered across several places." That distinction matters, because every judgment below rests on it: if you have one repository and one small, well-defined task, Projects is mostly overhead for you. If your work is naturally cross-repository and cross-document, that is where it starts to earn its place.

How it actually works

According to GitHub's official changelog, the flow has four steps. First, you create a project and state in plain language what needs to get done. Second, you attach the context Copilot needs: relevant repositories, design mocks, Slack threads, notes from a design meeting. Third, you choose the models and tools for the job. Fourth, Copilot runs as many agents as the work needs, in parallel in the background, and brings back results — such as pull requests — for your review. Along the way it checks in with you: when it needs a decision, it stops and asks, instead of pushing ahead and surprising you with a finished result.

The step most worth attention is the second one: context. The most common cause of agent failure has never been that the model was not smart enough, but that it did not know the background: that a requirement had already been debated for three rounds in Slack, that a design mock had been revised, that another repository already had an implementation. Projects turns "giving context" into a formal step, rather than something you improvise in the chat box each time. That sounds like a small improvement, but its impact is large. The fuller the context, the less likely the agent is to wander off track — but the messier the context, the more likely it is to be led astray. In the future, skill with Projects may depend less on "writing clever prompts" and more on "knowing how to choose context."

One more detail: for a focused task in a single repository, you can still start a session directly from that repository, without building a project. GitHub deliberately kept that lightweight path, which is a good sign. It suggests the designers did not force everyone to take a detour just to promote a new concept. In tool design, keeping an exit — a way to get work done well without the new feature — often says more about the designers' judgment than the new feature itself.

Automations: turning repeated work into a fixed routine

Projects also includes Project Automations, for repeatable tasks. GitHub's example is creating a new promo video whenever a feature lands. Work like this has a particular character: it is not hard, but someone has to remember it every time, it takes time every time, and it easily gets dropped when things get busy. Automating it is valuable less for "minutes saved" and more for "never missed again." For small teams, that "never missed" value is often underestimated: launch checklists, release notes, cross-repository syncs, documentation updates. The cost of missing one of these once is usually far larger than the cost of doing it by hand each time.

But automation has another side: it automates mistakes too. If a process is flawed, automation just makes it wrong faster and more neatly. If a video template is wrong, automation will reproduce the error faithfully in every release; if a cross-repository sync rule is wrong, automation will spread the error everywhere. So before automating, run the process by hand two or three times and find its pitfalls first, then fix it in place. That order cannot be reversed. Projects gives you a place to fix the routine, but it will not judge whether the routine itself is right.

Beyond code: Slack, Figma, and desktop apps are in

The Copilot app changes go beyond Projects. The same changelog mentions three more things: context from connected tools such as Slack and Figma for research, spec drafting, and design discussion; generating and editing images in chat with natural language; and Computer Use, letting Copilot work through tasks in desktop apps. Taken together, the intent is clear: GitHub wants the Copilot app to grow from "a coding tool" into "a place where work happens," where code is only one kind of output, alongside documents, design discussions, images, and even operations inside desktop software.

Computer Use is the one that most needs a cool head. According to the official description, it is also in public preview, on macOS and Windows only. It can read app content, click controls, enter or edit text, and navigate across apps, including apps with no API, no command line, and no MCP integration. The example given is an expense-report workflow. Before controlling an app, Copilot asks for your approval, and organizations can disable the feature through managed settings. On macOS, you must also grant Accessibility and Screen Recording permissions. None of these guardrails can be skipped, because an agent that can click a mouse carries a completely different risk profile from one that only edits text: clicking the wrong button could change a setting in a production console, whereas a bad line of code is at most a bad line of code.

For ordinary developers, the sensible position for Computer Use right now is "try it on small, controlled tasks," not "hand over everyday operations." Try it in a test environment, in an unimportant app, and watch whether it clicks where you meant, and whether it stops to ask when it is unsure. Once you know its temperament, consider widening the scope. Organization administrators should first decide which apps it may touch and which it absolutely may not, with a default of off and opened only on demand — not on first and fixed after an incident. The fact that GitHub provides an organization-level off switch is itself a reminder.

Session continuity matters more than it sounds

Another easily missed point in this release is session continuity. You can start and follow the same cloud agent session across the GitHub app, VS Code, the CLI, and the web, without re-explaining the background in each place. For people who move between devices and interfaces all day, that is genuinely valuable: a request raised on the web in the morning, continued in the editor in the afternoon, checked from the CLI in the evening, with no repeated carrying of context. But there is a cost: the longer a session runs, the more bloated its context becomes, and the more likely the model is to forget earlier agreements in the later stages, or to mix old decisions with new requirements. "Can continue" does not mean "should continue forever." Once a project or session reaches a certain size, it should be closed out, archived, and replaced with a fresh one, rather than extended indefinitely.

Put these pieces together, and GitHub's intent becomes complete: it is not selling a model that writes code better, but building a frame centered on work. Work has a goal, context, multiple agents, automations, and continuity across interfaces; code is just one material flowing through that frame. That direction matches how agent tools have evolved over the past few years: from completing a line of code, to completing a task, to coordinating many tasks. Projects is one node in that evolution, not the destination.

Judgment for small teams and independent developers

For small teams and independent developers, the most useful scenarios for Projects are quite specific. The first is a cross-repository feature: a change touching a frontend repository, a backend repository, and a documentation repository. In the past you opened three sessions and explained the background three times; now you can explain it once inside a project. The second is launch preparation that touches no code: release plans, promotional assets, cross-team coordination, work that used to live scattered across chat logs and documents and can now have one home. The third is repeated finishing work: the few things that must happen at every release, written as automations so they no longer depend on memory.

Conversely, several situations do not call for Projects right away. First, your task is a small change inside a single repository — opening a session directly is faster, and building a project is overhead. Second, your context itself is a mess: requirements unclear, three versions of a design mock, contradictory conclusions in Slack. Handing a mess to an agent in full only produces a bigger mess; sort out the context before bringing in the tool. Third, your review capacity cannot keep up: if Projects brings back multiple pull requests at once and you do not have time to review each one seriously, bulk output equals bulk buried risk. How much work an agent can do at once is limited by how much work you can review at once. That limit belongs to humans, not to models.

There is also a very practical open question: cost. GitHub's changelog gives no separate pricing for Projects, and no statement of how much AI credit parallel multi-agent work consumes. During public preview, the only safe approach is to test consumption on a small project first, then decide whether to scale up. Do not bet a quarter's development plan on a preview feature before seeing a bill. "Preview" means usable, but its behavior and pricing may still change.

The real bottleneck: can you review it all?

Every multi-agent tool eventually hits the same wall: output speed outruns human review speed. Projects lets Copilot run multiple agents at once and bring back multiple pull requests. That sounds wonderful, but if your team already struggles to review pull requests, this feature only lengthens the review queue. Worse, agent-generated pull requests often look exemplary: tidy formatting, complete descriptions, tests attached. That polish makes it easy to relax and approve faster than you would a colleague's code. And it is exactly those "looks fine" pull requests that most need a slower look: did it touch something you did not want touched, introduce a dependency you did not notice, or assume its way through an edge case?

So teams using Projects should set two rules up front. First, agent pull requests go through the same review standard as human ones — neither lowered because a machine wrote them, nor raised because they look pretty. Second, every project has a named owner who makes the final call, so that when something goes wrong, someone is responsible, rather than "the agent did it" being the end of the story. Tools can share execution, but they cannot share responsibility. That is a baseline for all agent tools, and Projects is no exception.

Context: how much, and what, is a new craft

Once Projects makes context a formal step, a new craft question appears: how much to give, and what. Too little, and the agent guesses, and you spend time correcting its guesses. Too much, and the agent grabs the wrong emphasis from a sea of information, or treats a superseded old conclusion as the latest decision. Worse, Slack threads and meeting notes often contain process history — "we said this at the time, then changed it" — and if everything is handed over without labels, the agent cannot tell which statement is settled and which was an overturned proposal. So before using Projects, do one round of context cleanup: mark the settled conclusions, remove superseded versions, and list open questions separately, so the agent works from clean material rather than an archaeological site.

That cleanup work is itself valuable. Many teams trying Projects for the first time will find that the biggest gain is not how much work the agent did, but that preparing context forced the team to state requirements, conclusions, and open items clearly. In a sense, Projects is a tool that forces you to think things through: if you have not thought them through, it hands you output that looks usable but does not match; if you have, it can genuinely take over execution. That rule applies to all agent tools, but Projects makes it more visible, because it mobilizes more context and more agents at once, and messy input gets amplified more dramatically.

There is also a permissions reminder: handing Slack discussions, design mocks, and several repositories to one project concentrates internal information that used to be scattered. Concentration brings convenience and risk: who can view this project, who can change its context, whether an agent-generated pull request could carry sensitive information from one repository into another. These questions should be settled before the first project is created. GitHub's changelog does not spell out the permission details, so teams must supply that lesson themselves: start with the smallest scope, include only the context needed for the task, keep sensitive repositories and channels disconnected until the process is proven, then widen gradually.

Image generation and desktop control are side dishes, not the main course

The image generation and Computer Use items in the same changelog easily steal attention, but for developers they are side dishes at this stage, not the main course. Generating and editing images with natural language is handy for promotional graphics, diagrams, and placeholders, but it does not solve design itself: what style you want, who it is for, what message it carries — a human still has to decide those first. Computer Use can click through desktop apps, which sounds like science fiction, but it is still public preview, and every step needs your approval, so the time it actually saves may be less than imagined, while the risk it introduces is real. Treat both as "nice to try" bonuses, not as reasons to adopt Projects, and do not let them overshadow its more solid value: organizing cross-repository, cross-document work.

A simple test for whether a new feature deserves your time is whether it lets you skip one repeated chore, or avoid one mistake you have already made. Projects passes that test, at least in logic, on cross-repository collaboration and repeated-task automation. Image generation and desktop control, at this stage, pass more on "looking impressive" than on time saved versus risk taken. Let them mature through a few preview rounds, with clearer permission and cost statements, before evaluating them seriously. Not every new tool in the box needs to be picked up on day one; letting it sit for a while is often the cheaper move.

Start with a real but non-critical job

If this article makes you want to try Projects, the safest first move is not to apply it to a core feature under deadline, but to pick a real yet non-critical job. For example, the closing checklist for a release: updating documentation in three repositories, putting together release notes, making a simple promotional image. Jobs like this have several advantages: the scope is clear, a poor result does no serious damage, and they happen to test Projects' three key points — whether cross-repository coordination runs smoothly, whether the context provided is enough, and whether automations miss steps. After one round, you will have a feel for its temperament, and then you can decide whether to use it on more important work.

During the trial, record three sets of numbers: first, how many pull requests the agent brought back at once, and how long you actually spent reviewing them; second, how long preparing context took, and whether it cost more than writing prompts directly; third, the rework rate — how many pull requests were usable as-is, and how many needed major changes. Those three numbers will tell you more than any marketing copy about whether Projects saves or costs your team time. If reviewing takes longer than the execution time it saved, then for you, at this stage, it is a net loss. Set it aside and come back when it is more mature. Tools exist to serve you, not to make you work overtime for them.

One final, larger judgment: the Copilot app is changing from "an assistant inside the editor" into "a workbench." Whether that change is right depends on whether it solves friction in real work, not on how many agents it can run at once. Projects answers a real problem: work itself is cross-repository, cross-document, and cross-tool, while tools have long been locked inside a single repository. That step points in the right direction. Whether it truly saves small teams time and helps them avoid pitfalls will only be known after enough people have used it on real projects in public preview, hit problems, and worked out how to use it well. The most sensible approach right now is to try it at small scale on a real but non-critical project, review every output seriously, work out the cost, and then decide how large a place it deserves in your workflow.