What happened
TechRadar reported on October 24 that it tested the fine print around ChatGPT’s Locked Chats feature. Locked Chats lets a user put selected conversations behind a PIN and move them out of the ordinary chat history, pinned chats, and search. The report’s central finding is that the feature has boundaries that are easy to miss if “locked” is read as a general guarantee of confidentiality.
First, the report says a conversation can remain open in the same browser tab immediately after it is locked. That means locking a chat does not necessarily change what is already rendered in the active session. The report also says another device may continue to show the conversation title briefly until that device refreshes. These are interface and session behaviours, rather than evidence that the lock has failed; nevertheless, they matter in shared-device or shoulder-surfing situations, where a user may expect the screen state to change at once.
The workflow also requires active re-locking. According to the report, once the Locked Chats project has been unlocked, navigating away does not automatically lock it again. The user has to select Lock again. A person using the feature as part of a routine for handling sensitive work therefore needs to account for the state of the currently open session, not simply the existence of a PIN.
The report describes two additional boundaries outside the visible chat list. A shared link created before a chat is locked continues to work until the user deletes that link. Locking the conversation is therefore not a revocation mechanism for material that has already been shared. Separately, information ChatGPT had memorized before a chat was locked stays in regular Memory and must be removed manually. The report also notes a destructive recovery path: resetting a forgotten PIN permanently deletes all locked chats and protected files.
TechRadar recommends Temporary Chat for conversations that are genuinely sensitive. The supplied material does not present this as a product-policy change or a newly announced setting. It is a report of observed caveats in the way an existing privacy feature behaves, and of the operational distinction between hiding a conversation in the product interface and controlling the other places where its contents may persist or remain accessible.
What the archive adds
This is a new fact on a known story, not a new feature announcement. Our earlier notes had already framed Locked Chats as a visibility and access-control layer rather than a stronger confidentiality guarantee: Keep sensitive conversations out of view with Locked Chats in ChatGPT, Using locked chats in ChatGPT, and ChatGPT Now Lets You Lock Sensitive Chats Behind A PIN. The reported tab, link, and Memory behaviours give that distinction concrete operating cases.
Trend signal
This narrowly supports Agent security moves to runtime boundaries. A PIN-gated view can reduce accidental exposure, but the report illustrates why a visible interface lock is not the same thing as a boundary over already-open sessions, shared access paths, retained information, or recovery procedures.
Why now
The timing follows the recent rollout of Locked Chats. The earlier archive items date from October 22, while TechRadar’s reported testing is dated October 24. The useful new question is therefore not whether the feature exists, but what its lock changes—and what it leaves unchanged—in day-to-day use.
Why it matters
Teams increasingly place work context, customer details, drafts, and internal discussions into general-purpose AI chat products. A feature that hides selected conversations can be useful when devices are shared or screens are visible to colleagues, but it should not be substituted for a data-handling policy. The reported behaviours create several separate checks: whether a chat is still open locally, whether another device has refreshed, whether anyone has a pre-existing shared link, and whether relevant details have entered Memory.
For builders, the larger lesson is to model privacy controls by their scope. “Protected by a PIN” is not enough information to determine whether content has been removed from search, detached from memory, revoked from external sharing, or cleared from an active session. These are different controls with different failure and recovery modes.
What happens next
- ChatGPT users will ask for clearer explanations of what Locked Chats do not revoke or erase. (3 months, 60%). Watch for: product documentation or interface copy that distinguishes chat visibility, sharing, and Memory.
- Privacy-conscious workflows will continue to use temporary conversations for the most sensitive prompts. (6 months, 65%). Watch for: guidance that separates temporary sessions from locked history.
Limits and uncertainty
This account is based on TechRadar’s testing and description, not on a supplied OpenAI specification or independent reproduction. The material does not establish how long a stale title can remain visible on another device, which browser or device combinations were tested, or whether behaviour differs by account, plan, region, or product version. It also does not say precisely what kinds of information can enter Memory, how memory removal is surfaced, or whether deleting a shared link affects copies made by recipients. The report identifies practical caveats, but it is not a comprehensive security assessment of ChatGPT.
Skill to build now
Write a short handling rule for conversational AI this week. Classify material into three buckets: content safe for ordinary chat history, content suitable for a visibility lock, and content that should use a temporary session or stay outside the product. Before relying on a lock, check four things: active browser tabs, logged-in devices, previously created shared links, and saved Memory. Treat PIN recovery as a data-loss scenario and ensure the people using the account know that resetting it can delete protected chats and files.
Reader takeaway
Locked Chats can add useful friction against casual access, but they are not a complete privacy boundary. If a conversation is truly sensitive, consider the session state, sharing history, and Memory separately—and use Temporary Chat when the requirement is to avoid retaining the conversation in ordinary history.