General Chat is silently archived after session resume timeout, with no restore UI

Summary

A long-running General Chat was silently archived when the app failed to resume it within 60 seconds. I did not archive or delete the chat. The app automatically created a replacement chat, while the original disappeared from the sidebar with no UI to view or restore archived chats.

Environment

• GitHub Copilot app: 1.1.8 (0945da4)
• Bundled Copilot CLI: 1.0.79-9
• OS: Windows x86_64

Observed behavior

1. Opened an existing General Chat with substantial history.
2. The UI appeared unresponsive for about a minute.
3. The original chat disappeared and a newly created chat became active.
4. The original chat was absent from the session list.
5. Attempting to navigate to its ID returned: This chat is archived. Restore it before continuing.
6. There is no archived-chat list or Restore action in the app UI.

The local database showed that the original general_chat row received an archived_at value at exactly the same time the replacement session was created. Clearing only that archived_at value restored the original chat and its full history, confirming the data had not been deleted.

Relevant sanitized log timeline

09:36:25 resuming session ... session_type=GeneralChat
09:37:25 session resume timed out; releasing CLI and surfacing error ... timeout_secs=60
09:37:26 Failed to resume session ... the CLI process may be unresponsive, attempting to recreate
09:37:26 Recreating session old_session_id=<original>
09:37:33 CLI session created cli_session_id=<replacement>
09:37:33 SessionManager create_session flow completed session_id=<replacement>

The original row's archived_at timestamp was 09:37:33.779, immediately after the replacement session was created.

Expected behavior

• A resume timeout must not silently archive an existing chat.
• If a replacement process/session is needed, the existing chat identity and history should remain visible and recoverable.
• The app should surface the timeout and offer Retry rather than replacing the chat without consent.
• If chats can be archived, the UI must provide an Archived view and Restore action.

Impact

This looks like data loss to the user and strands important long-running chat history. Recovery currently requires manually editing the app's SQLite database, which is not a safe or reasonable user workflow.

Commencez par reproduire le délai d’expiration de reprise de 60 secondes et inspectez le flux SessionManager create_session en parallèle de la modification de archived_at dans la ligne SQLite locale. Vérifiez que le chat d’origine reste visible et récupérable, que le retour du délai d’expiration propose Retry et que les chats archivés disposent d’une vue et d’une action Restore.