Add rollback, per-release update holds, and clear version reporting

[karelz]

Feature summary

Add rollback, temporary per-release update holds, and clear version reporting

What problem are you trying to solve?

When an automatic desktop app update introduces a serious regression, there is no safe in-app way to return to the previous version or skip only the broken release. Manual uninstall, reinstall, and update pinning are disruptive and may put local data or settings at risk.

Version reporting is also ambiguous. On Windows on 2026-09-07, installed-product registration and github.exe report app 1.1.15, the bundled Copilot CLI reports 1.0.83-5, and WinGet reports 1.1.15 installed while its catalog offers only 1.1.14.

Proposed solution

1. Add an in-app Roll back to previous version action.
2. Add Skip/Hold this version: stay on the working version, show that updates are held, and automatically resume updating when the next release appears.
3. Preserve user data and settings, warn about incompatible data-schema changes, and provide a safe restart flow.
4. Clearly label the desktop app version, bundled CLI version, and latest updater/catalog version in About, update UI, and diagnostics.

Workflow impact

Recent reports show why a recovery path is useful; they do not imply every user is affected:

• github/app#3558: 1.1.15 can leave the main window permanently blank after renderer crashes.
• github/app#3574: 1.1.15 can make all worktree-backed sessions unusable.
• github/app#3575: 1.1.15 can add about 30 seconds to every session creation.
• github/app#3563: persistent CLI processes can consume about 15 GB and make the Windows UI nearly unusable.
• github/app#3590: queued instructions can be silently lost from both delivery and durable history.

Installation context

Windows 11; desktop app 1.1.15; bundled CLI 1.0.83-5; WinGet package GitHub.CopilotApp.

Additional context

Current Windows workaround:

winget uninstall --id GitHub.CopilotApp --exact
winget install --id GitHub.CopilotApp --exact --version 1.1.14 --source winget --accept-package-agreements --accept-source-agreements
winget pin add --id GitHub.CopilotApp --exact --blocking

Resume when 1.1.16+ is available (which requires manual check, or automated daily task in Copilot):

winget show --id GitHub.CopilotApp --exact --versions
winget pin remove --id GitHub.CopilotApp --exact
winget upgrade --id GitHub.CopilotApp --exact

A WinGet pin controls only WinGet and may not block the app's updater, does not auto-expire for the next release, and WinGet can lag behind app releases. I assume I would also have to disable the GH Copilot app's automatic updates to prevent 1.1.15 from being offered again; that would delay adoption of 1.1.16+ until I notice it and re-enable updates manually. Related issues github/app#2284, github/app#3571, and github/app#3242 cover parts of the update experience, but not this complete rollback, one-release hold, and version-reporting workflow.

[karelz]

Sadly, manual rollback does not work because, old version cannot read new version data (not that much surprising)

Perhaps creating some compat shim or data export to allow old version to read new version data (best effort for 1-2 release) would pay off.
After this experience, I will think twice before upgrading to newer version ;(

[brandonmartinez]

@karelz I tried that exact same thing to be greeted with the warning (it's the same on macOS, as to be expected) :(

[karelz]

A friend and colleague, @vitek-karas, hit the same problem (need to rollback) and found a workable recovery path -- although it is a bit Copilot-based reverse engineering and not officially supported path. But hey, if it works and unblocks people ...

Disclaimer: I had no time to independently test it myself yet (not enough pain / too much things to do), but I trust him.

Idea

The important part is that the updater creates a pre-update database backup: restoring only the older app is not enough, because 1.1.14 cannot open the database after 1.1.15 has migrated it.

At a high level, with Copilot fully stopped:

1. Preserve the current data.db, data.db-wal, and data.db-shm.
2. Find the automatically created data.db.pre-update-backup-1.1.15-* backup, whose path should also appear in the app log.
3. Restore a copy of that backup as data.db.
4. Uninstall 1.1.15, install 1.1.14, and pin it.

That worked for him on Windows. The same recovery principle may work on macOS if the updater creates an equivalent pre-update backup, but these paths and commands are Windows-specific and he has not tested the procedure on macOS. In particular, 1.1.14 should not be launched against the database migrated by 1.1.15, and the SQLite files should not be modified while Copilot is running.

Detailed steps

• See the attached MD file for detailed instructions:
  copilot-1.1.15-to-1.1.14-rollback.md