One Copilot Should Not Mean Lifetime Memory
GitHub is unifying Copilot chat and cloud agents, but that merger also extends chat retention from 28 days to an account's lifetime.
Twenty-eight days and the lifetime of an account are very different answers for when a chat should disappear.
They now sit on opposite sides of a product merger. In an August 28 changelog, GitHub said Copilot’s cloud agent, chat on github.com, and mobile chat will become one experience no earlier than September 28. The unified version will be enabled by default. GitHub also says chat data on github.com will be kept for the life of the account instead of 28 days, matching the cloud agent’s existing policy.
The announcement does not say that GitHub hid the change. It tells business and enterprise administrators to review the policy before launch, and DevOps.com independently called out the retention shift as a concern for organizations with audit, contractual, or data-governance requirements.
Still, the new default bothers me. A simpler interface is not a good reason to give ordinary chat the longest retention rule available.
One box can hold unlike records
There is a sensible case for preserving cloud-agent sessions. An agent may research a repository, produce a plan, change files on a branch, and respond to review. Its conversation can explain why a patch exists long after the run ends. Teams may need that record for an audit or a post-incident investigation. Deleting it automatically after four weeks could remove useful context while the branch and pull request remain.
Longer retention can help continuity too. A person returning to unfinished work should not have to reconstruct every instruction because the calendar crossed an arbitrary line. GitHub is also trying to remove policy seams between surfaces that increasingly perform the same work. One account-wide rule is easier to explain and administer than several rules whose boundaries shift as features converge.
That argument does not make every prompt a permanent work artifact.
A quick question about a failing test is not necessarily the same kind of record as an agent session that opened a pull request. Mobile chat may collect half-formed questions, copied error messages, repository details, or context that was useful for ten minutes. Even careful developers paste more than they intended sometimes. Retention does not prove that this material trains a model, and GitHub’s notice does not make that claim. It simply means the service keeps the chat data. That is enough to increase the period during which an old mistake, confidential snippet, or forgotten conversation exists on somebody else’s system.
“Lifetime of the account” is not much of a retention schedule. A developer account can survive several employers and hundreds of abandoned projects. An organization account may outlive the team that created a session. The date depends on a much larger decision than whether one conversation remains useful.
Unification should preserve deletion choices
I would rather GitHub classify the record by what happened in it.
An ordinary chat could keep a short default window. A cloud-agent run tied to a branch or pull request could follow an organization-defined project policy. GitHub could offer explicit choices such as 28 days, 90 days, one year, or account lifetime, with administrators allowed to set a maximum. If a session needs to become a durable artifact, a user should be able to preserve or export it deliberately instead of receiving permanence through a renamed default.
The interface should also show the consequence where the conversation starts. A small line saying when the session will be deleted would be more useful than expecting every developer to have read an August changelog. Deletion should be available per session and in bulk. If legal hold or audit policy prevents removal, the interface should say that plainly rather than presenting a button that cannot honor the request.
This would add policy work. Separate retention classes create edge cases when a chat becomes an agent run halfway through, or when one session touches several repositories with different rules. Administrators already have too many settings, and GitHub has a legitimate reason to avoid a matrix that nobody understands.
GitHub does not need a sprawling matrix to do better. Keep a short default until the session creates a durable repository artifact. At that boundary, show the new retention rule and let the organization decide. GitHub already knows when Copilot opens a branch or pull request. That event is more meaningful than which screen contained the first prompt.
The opt-out described in the announcement is too coarse for this purpose. GitHub says people or teams that decline the unified experience will lose Copilot on github.com and mobile after launch. That turns a data-retention objection into a product-access decision. Someone should be able to use the chat without accepting account-lifetime storage for every conversation.
Consolidation is useful when it removes duplicate controls and makes behavior easier to predict. Here, the most persistent component appears to set the lifespan for everything beside it. That is a rotten inheritance rule for data.
One Copilot button may be simpler. I still want a real deletion date attached to what happens after I press it.