Fix Copilot ‘Connection Lost’ Error During Long Conversations

Official documentation checked October 14, 2026.

If Copilot reports “Connection Lost” during a long conversation, preserve the last prompt and useful results before refreshing. The message alone does not establish a 60-minute session expiry, an attachment-volume cutoff, or permanent loss of the conversation.

Recover in small steps, then compare the account, client, conversation, and connection to identify the scope. Keep required VPN, proxy, and authentication protections in place while investigating.

Why Copilot Can Lose a Connection During a Conversation

Microsoft’s Copilot requirements identify WebSocket Secure connectivity as a dependency. Blocking WSS, interfering TLS inspection, or aggressive proxy timeouts can disrupt integrations. That describes possible network conditions; it does not prove which condition caused your banner.

Authentication also needs actual evidence. Microsoft’s identity-platform token documentation describes variable lifetimes and renewal rather than one universal 60-minute limit. Much of that page applies to registered APIs, with separate qualifications for Microsoft-owned services. It cannot establish that Copilot never refreshes tokens or disconnects every hour.

Conversation size and file limits depend on the experience. Check the actual limit or error for your app and attachments instead of assuming a fixed prompt count explains a disconnect. Starting a fresh conversation can be a useful comparison without proving the original is irrecoverable.

Steps to Recover From a Connection Lost Error

1. Save before refreshing. Preserve unsent text, the last completed answer, relevant source names, and the task’s current state in an approved private location. Save open documents. For an editing or other action request, inspect whether the action partially completed before repeating it.
2. Record the failure. Note the exact app or website, account type, time/time zone, full message, app/build, and any request ID. Record whether the device woke from sleep, the network changed, or a sign-in prompt appeared.
3. Reload the actual client. In a browser, use its normal Refresh control after preserving text. In an Office app, close and reopen the Copilot pane using the available control; if needed, save work and restart that app. Ctrl+Shift+R is not a documented universal Office Copilot-pane reset and does not guarantee a new token or preserved unfinished response.
4. Try one harmless request. Compare a short request in the current conversation and a new one. If a new conversation works, carry forward a concise task brief, checked results, and necessary source references. Check available history before declaring the old conversation lost.
5. Complete a legitimate sign-in challenge if shown. Use the intended account and normal authentication method. If access is blocked, give IT the event time and correlation details. Do not delete saved credentials or change MFA policies based solely on this banner.
6. Check a matching shared incident. An administrator can review Health > Service health using Microsoft’s service-health instructions. Match the affected Copilot experience and time before applying an incident workaround.
7. Run the approved connectivity check when needed. The current network test guide links the Microsoft 365 connectivity test. It describes Run test and a Copilot WebSocket result in the details pane. Share the relevant result with your network team. Signed-in reports are uploaded to the tenant and shared with its administrator; advanced tests can require a downloaded client.

Use a stable approved connection for the comparison. If testing a different network is permitted, record that condition while keeping the required corporate access controls active. A better result narrows the investigation but does not automatically identify one network device.

If Copilot Keeps Disconnecting

It reconnects and fails again

Compare the time and WebSocket result with IT’s proxy, firewall, and sign-in evidence. The current requirements list *.office.com, *.cloud.microsoft, and copilot.cloud.microsoft for WSS. Use the complete current endpoint guidance appropriate to the service. Do not bypass all inspection or broadly unblock every Bing subdomain as a generic repair.

Only the original conversation fails

Continue with a checked brief in a new conversation and retain the original history if available. Split a large task by named document sections or work units, then verify source coverage. Choose boundaries that retain the assumptions and notes needed to understand each part. A refresh does not guarantee preservation of the entire context.

Every conversation fails

Compare the same account in another supported client and check for service and access failures. That symptom is not proof of a damaged local installation. If support identifies a desktop application issue, use Microsoft’s Office repair route with work saved; it affects the suite and does not fix an upstream blocked service.

Conversation, Client, and Network Failures Compared

Keep the successful retest and the condition that changed. Do not buy a different Copilot plan or reset the conversation on a 45-minute timer on the assumption that a fixed expiry or dedicated routing guarantees stability.