Share via

Why does Copilot destroy entire sessions when signing in — and why is Microsoft using forced‑consent dark patterns?

Corbarian 5 Reputation points
2026-06-12T16:48:59.6766667+00:00

This post documents three major data‑loss incidents and multiple systemic failures while using Copilot inside the Microsoft ecosystem (Windows 11, Edge, Microsoft 365 subscription). The behaviour demonstrates predictable, preventable, repeated user harm caused by architectural decisions in the Windows/Edge/Copilot platform layer.

I am posting this publicly because the failures are severe, reproducible, and have consumed days of work.

1. Summary of Failures

Copilot repeatedly prompted me to sign in during active work.

When I finally signed in, the entire session was destroyed without warning.

This is the third time a major piece of work has been lost.

The behaviour is not accidental; it is a known architectural flaw.

  • I am using a fully Microsoft environment: Windows 11, Edge, Microsoft 365, and Office.

2. Technical Critique of Copilot Architecture

Fragmented System Architecture

Copilot runs as an ephemeral, stateless web session.

Identity/authentication is a separate global service.

These systems do not communicate, causing destructive resets.

Predictable Data Loss

Signing in invalidates the active session.

This wipes all user inputs, uploads, and generated content.

No autosave, no recovery, no continuity layer exists.

This behaviour is known and reproducible.

Missing Basic Safeguards

No warning is shown before a destructive session reset.

Adding such a warning is a trivial engineering task.

Its absence is a design decision, not a limitation.

Misleading Integration Claims

Microsoft 365 implies an integrated ecosystem.

In practice, Copilot cannot access OneDrive.

It cannot maintain session continuity.

It cannot output Word‑compatible formatting reliably.

It cannot generate basic file formats (e.g., DXF).

  • Copilot behaves like a disposable web widget, not an integrated assistant.

3. User Impact

Repeated Loss of Substantial Work

Three major incidents of data loss.

Each incident resulted in days of wasted work.

No recovery mechanism exists.

Failure to Support Complex Tasks

CAD work: Copilot could not output a valid DXF file after days of attempts.

Ombudsman complaint: Copilot could not process documents over 200,000 characters; required manual chunking.

Building Regulations submission: Copilot produced verbose, inconsistent output and then lost the entire session.

Productivity and Trust Impact

Repeated interruptions and data loss undermine confidence in Microsoft tools.

  • The behaviour contradicts the expectations set by a Microsoft 365 subscription.

4. Procedural Failures

Failure to Warn

No warning that signing in would erase the session.

This omission is negligent given the known consequences.

Failure to Protect User Data

No autosave.

No session persistence.

No recovery.

No continuity across sign‑in events.

Failure to Align Product Behaviour With Marketing

Microsoft 365 is marketed as integrated.

Copilot behaves as a siloed, stateless tool.

The user reasonably expects continuity; the system does not deliver it.

Failure to Address Known Issues

These behaviours are long‑standing and widely reported.

No visible remediation has been implemented.

  • The absence of a warning dialog is indefensible.

5. Forced‑Consent Dark Pattern in Microsoft Learn Registration

To post on Microsoft Tech Community, users are forced to register with Microsoft Learn.

Registration requires ticking a checkbox labelled: “I would like to receive information via email related to my use of Microsoft Learn.”

The wording implies a voluntary preference, but the UI blocks progress unless the user ticks it.

This is a forced‑consent dark pattern: consent is mandatory, the wording implies it is optional, and the user cannot proceed without agreeing.

This undermines trust and violates basic UX transparency principles.

  • It is inappropriate for a platform that claims to support professional and technical communities.

6. Why Microsoft’s Managers Don’t See These Failures

Internally, Microsoft operates inside a bubble of curated success, where internal demos and controlled scenarios consistently succeed while real‑world failures rarely reach decision‑makers.

Managers do not use the product in the same way real users do; they rely on curated test paths that avoid the problems described here.

Metrics presented to leadership hide user pain by averaging it away.

Fragmented ownership means no one is responsible for the end‑to‑end user experience.

  • As a result, destructive behaviours that are obvious to users remain invisible to those with the authority to fix them.

7. Requested Actions

  • Add a mandatory warning before any sign‑in event that resets the session.
  • Implement session autosave and recovery.
  • Implement persistent workspace continuity tied to the user’s Microsoft account.
  • Improve Word‑compatible output formatting.
  • Improve file‑format generation (e.g., DXF).
  • Provide transparent documentation of Copilot’s limitations.
  • Remove forced‑consent email opt‑ins from Microsoft Learn registration.
  • Address the organisational blind spots described above.

8. A Note on User Contribution, Harm, and Reasonable Expectation of Compensation

This complaint represents substantial unpaid labour undertaken to identify, document, and articulate systemic issues across multiple Microsoft platforms.

The level of detail provided here is equivalent to the work of a senior UX auditor, technical architect, and product‑integration reviewer; it exposes failures that internal teams cannot see from within their insulated environment.

The work was not voluntary in the usual sense; it was forced by repeated product failures, data loss, and the absence of basic safeguards. The time invested was significant, the impact was personal, and the harm was avoidable.

Given the scale of the issues uncovered, the professional‑grade analysis provided, and the direct consequences of the failures described, it is reasonable to expect Microsoft to offer compensation or a goodwill gesture recognising both the value delivered and the cost imposed.

Users should not be expected to donate consultancy‑level diagnostic work simply to make core products behave safely and predictably; at minimum, this contribution warrants the seriousness and acknowledgement normally reserved for paid professional input.

In light of the effort, expertise, and persistence required to document these failures, I expect Microsoft to respond substantively and to recognise this contribution appropriately, including through compensation.

Microsoft Copilot | Windows Copilot | Feature

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-12T16:49:41.81+00:00

    Copilot experiences today are designed as cloud-based, conversational sessions that are not guaranteed to persist across sign-in changes, app restarts, or browser events. The behavior described aligns with several documented characteristics and limitations of Microsoft 365 Copilot and Copilot system design:

    1. Session behavior and data loss
    • Copilot interactions are treated as conversations, not as durable documents. Prompts and responses are stored as Copilot activity history, but the UI session itself (the visible chat, uploads, and intermediate state) is not documented as a guaranteed, recoverable workspace.
    • Microsoft 365 Copilot stores “the interaction in the user's Copilot chat history” so users can review and reuse previous prompts, and users can delete that history. There is no documented guarantee that an in-progress, unsigned-in, or partially authenticated session will survive a sign-in transition or other lifecycle events.
    • Copilot is explicitly described as an orchestration layer over LLMs, Graph data, and Microsoft 365 apps, not as a file-based authoring surface with autosave semantics like Word or OneNote.

    Given this design, signing in can effectively start a new authenticated context, and the product documentation does not claim that all transient UI state (including uploads and generated content not saved elsewhere) will be preserved.

    1. Safety, mitigations, and architectural priorities

    The official materials emphasize:

    • Responsible AI and safety mitigations (content classifiers, metaprompting, harmful-content blocking, prompt-injection protection) as core engineering priorities.
    • Grounding in business data via Microsoft Graph, with strict adherence to existing permissions and role-based access controls.
    • Phased release and continual evaluation, with red teaming and automated evaluations focused on harmful content, jailbreaks, ungrounded content, and similar risks.

    These priorities mean that much of the engineering and evaluation effort is directed at safety, compliance, and access control rather than at long-lived conversational workspaces or autosave/recovery of chat content.

    1. Integration with Microsoft 365 data
    • Microsoft 365 Copilot is designed to access organizational data through Microsoft Graph (emails, chats, documents) that the user is authorized to access. It does not claim to have arbitrary file-system or OneDrive-like behavior inside the chat itself.
    • Copilot “only accesses data that an individual user is authorized to access” and cannot see data outside those permissions. This access model is enforced via existing Microsoft 365 controls (for example, Restricted SharePoint Search, SharePoint Advanced Management, Microsoft Purview).
    • The documentation does not state that Copilot chat is a general-purpose file generator with guaranteed support for all formats (such as DXF) or that it will always produce perfectly structured, Word-ready output. Instead, it highlights that LLMs can generate ungrounded or inaccurate content and that users must review and verify outputs.
    1. Known limitations and ungrounded content
    • Microsoft explicitly acknowledges that LLMs can generate ungrounded or incorrect content and that Copilot may include information not present in source materials.
    • Users are advised to treat outputs as assistive, verify against sources, and use judgment. This applies equally to complex tasks (long documents, regulatory submissions, CAD-related content) where model limitations or token limits can require chunking or manual structuring.
    1. Risk management and product evolution
    • Copilot and Microsoft 365 Copilot are under phased release plans and continual evaluation. Red teaming and automated evaluations are used to map, measure, and manage risks, and Microsoft states that mitigations and product behavior are updated iteratively.
    • Mitigations include classifiers and system messages to reduce harmful or problematic content, and content filters that may block or alter responses.
    • The documentation notes that generative models are probabilistic and can make mistakes, and that mitigations may occasionally fail.
    1. Data, privacy, and training
    • For Microsoft 365 Copilot, prompts, responses, and data accessed through Microsoft Graph are not used to train foundation LLMs, including those used by Copilot.
    • Copilot operates with protections such as blocking harmful content, detecting protected material, and blocking prompt injections.
    1. Image and biometric handling
    • When users upload images with faces, Copilot requires explicit consent before biometric data is uploaded. Images are deleted within 30 days after the conversation ends. This illustrates that some aspects of the system are intentionally ephemeral for privacy and safety reasons.
    1. On UX issues, dark patterns, and compensation
    • The provided documentation focuses on system behavior, safety, privacy, and architectural principles. It does not describe or endorse forced-consent patterns in registration flows, nor does it provide guidance on compensation or goodwill gestures for user-reported issues.
    • It also does not specify UX guarantees around warnings before session resets, autosave of chat state, or workspace continuity across sign-in events.
    1. Practical implications for complex work

    Within the documented design:

    • Copilot chat should be treated as an assistive, conversational tool whose content needs to be exported or copied into durable storage (Word, OneDrive, local files) for any work that cannot be safely lost.
    • For long or complex tasks (large documents, regulatory submissions, CAD workflows), it is necessary to account for model limitations, token limits, and the lack of guaranteed session persistence.

    For changes such as mandatory warnings on sign-in, autosave/recovery of chat sessions, persistent workspaces, expanded file-format support, or UX changes to consent flows, the appropriate path is to submit product feedback through official Microsoft channels so it can be considered within the ongoing “phased release and continual evaluation” process described in the transparency and architecture documentation.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.