Copilot Is Starting to Manage Projects—Can It Really Handle Cross-Repository Work?

GitHub has put Projects in the Copilot app, in public preview. It turns giving Copilot a goal into an operable project: goals, repositories, sessions, artifacts, and scheduled tasks all hang under the same project. The most scattered context in cross-repository work now at least has a centralized entry point.

It solves the problem that cross-repository work has no common landing point. Copilot used to be more like one session after another; Projects collects sessions and artifacts under one goal. X user seridarivus says that for projects spanning multiple repositories, shared chat history alone isn't enough—the useful unit is the goal, with sessions and artifacts attached to it. That judgment is closer to reality than the official copy.

The creation entry point is Projects in the sidebar. When creating a new project, you can choose repositories or leave them unselected. Then write the goal, initial tasks, desired outcome, and constraints clearly in the prompt; if you need materials, first add files or folders in Library. The official example is investigating customer feedback on a new search feature: group by theme, summarize the main issues, provide evidence and open questions, use only the provided materials, and do not change code. Projects are not just for writing code; they can also organize materials and prepare for decisions.

The management interface groups items by status: Needs input, Open, Working, and Done. Needs input is the key one; it contains items that need your decision, review, or authorization. Clicking into a single session lets you see the conversation, changes, PRs, and plan, and you can give direction in Steer this session. It feels more like an ongoing workbench, with one-off Q&A making up only one part of it.

Scheduled tasks are described in the project conversation. For example, every Monday at 9 a.m., summarize the customer feedback in Library, group it by theme, provide examples and open questions, and use only the provided materials. The Automations tab shows the schedule and next run time, and lets you pause, change the time, or delete it. X user Sahil asks whether repeated runs will remember previous findings and whether new runs automatically pick up the prior context. The official docs don't give a definitive answer, so you need to watch this in actual use.

The hardest part of cross-repository projects is dependencies. Guilherme Ferreira says that when one goal spans multiple repositories, context is most easily lost; the real test is changing one repository and breaking a neighboring repository to see whether the agent can detect it. This test is more meaningful than the feature description 'projects support multiple repositories.' Luna's concern is more practical: the requirement only asks to change A, but it also refactors B along the way. She wants it to first list which repositories it plans to touch and get confirmation before starting work. That request is not unreasonable.

There's another counterintuitive point: a project doesn't have to depend on a repository. Bessi S says it's pretty funny that GitHub would ship a Copilot project that doesn't need a repository. Funny or not, it shows exactly that projects manage goals, and a code repository is just one kind of vehicle. Investigating feedback, organizing materials, and tracking tasks can all happen without a repository. GitHub has raised the boundary of a project one level above repositories.

It's suitable for people who have cross-repository goals and need ongoing follow-up. If you just want to ask a few code questions in a single repository, opening a session directly is lighter. Projects is still in public preview, and features will change. First write the goal clearly, manage Library materials well, and take Needs input seriously. The demo in the video is faster than text; you can watch it first to see how it brings sessions, automations, and artifacts into one project.

Official docs: Working with projects in the GitHub Copilot app

Original post: GitHub on X