Quick Summary: Reporting describes a ChatGPT feature that lets users lock selected conversations and require a PIN or supported device authentication to open them. The feature adds a privacy barrier around chats but should not be described as end-to-end encryption.
What the conversation lock actually changes
Locked Chats aim to add a barrier around selected conversations so they are less exposed in the ordinary chat list. The feature is useful for reducing casual access on a shared or unattended device, but users should review how the lock is activated and how notifications, backups and linked devices behave. A locked view should not be mistaken for a guarantee that every copy of a conversation is inaccessible.
Privacy depends on the full account and device setup, not just one interface setting. Users should keep their device passcode secure, review notification previews and linked devices, and understand the backup settings that apply to their account. The feature should be described according to its documented behaviour rather than labelled as end-to-end encryption beyond the protections the service already provides.
Locked conversations are separated from the ordinary history view, pinned chats and search. Retention, account security and model-improvement settings remain governed by the user’s account or workspace configuration.
Limits that remain outside the lock screen
People sometimes use ChatGPT on shared devices or keep conversations that they do not want immediately visible in a chat list. A lock can reduce casual access, but it does not remove the need to secure the device and the account itself.
Users should not assume that locking a conversation deletes server-side data, changes retention rules or prevents every form of account access.
Review the feature’s availability in your account, use a strong device passcode, check notification previews and review active sessions. For sensitive information, understand the account’s data controls before sharing details that should not be retained.
Account settings to review alongside the feature
OpenAI’s support documentation and release notes should clarify rollout, authentication methods, behaviour on linked devices and any limits. Those details matter more than describing the feature with broad security labels.
A lock on the interface is not the same as end-to-end encryption, a device-level security boundary or a guarantee that every copy of a conversation has disappeared. Account access, linked devices, notification previews, backups and workspace retention rules may still matter. People who handle sensitive material should review these layers together instead of treating one new setting as a complete privacy solution.
Before using the feature for confidential work, check whether locked conversations remain accessible through search, notifications, exports or connected clients, and understand how recovery works if the PIN is forgotten. Organisations should also consider workspace policies that control retention and administrator access. Accurate wording matters: the feature adds a layer of interface privacy, but should not be described as stronger encryption unless the technical design supports that claim.
The distinction matters most when users handle confidential work or personal information on shared devices. A conversation may still be available to an account administrator under workspace rules or retained according to the service’s policies even if it is hidden from the ordinary list. Users should not assume that locking a chat changes retention, training or administrative access settings. Those controls should be reviewed separately in the account or workspace configuration, especially when the chat contains client information.
Users should also check the recovery path before locking a conversation. A feature that relies on a local PIN or device authentication can behave differently when a user changes phones, signs in on another device or loses access to the original authentication method. The app should explain what happens in those cases without implying that the lock provides protections beyond its documented scope. Clear recovery instructions help prevent a privacy feature from becoming an unexpected access problem.
The feature’s boundaries should be explained in plain language inside the product. Users need to know whether the lock hides a conversation only from the main list or also changes access from notifications, linked devices and account exports. They should also be able to open the chat reliably without weakening the device’s main security. A short feature label cannot communicate all of those distinctions, so documentation and clear settings are part of the privacy design.