DEV Community: R.Shanmugaraj

ChatGPT's New Memory System Gave Me a Privacy Wake-Up Call

R.Shanmugaraj — Sat, 20 Jun 2026 15:08:31 +0000

I thought it was hallucination. It wasn't. It was something worse.

By Shanmugaraj Rajkumar | June 2026 · 6 min read

A few weeks ago I asked ChatGPT a health question. Completely routine — nothing technical, nothing related to my usual coding or job prep sessions.

Within a few responses, ChatGPT started referencing details from a conversation I had months ago. A conversation I never mentioned. Never linked. Just silently stored somewhere and quietly injected into my current chat.

My first reaction: hallucination. ChatGPT is making things up again.

But it wasn't random. It was specific. Too specific to be fabricated. That's when I started digging — and what I found changed how I think about AI privacy entirely.

What Actually Happened

On June 4, 2026, OpenAI rolled out Dreaming V3 — a background memory system that scans your entire ChatGPT conversation history, builds a synthesized profile about you, and injects it into every new conversation before you type a single word.

No pop-up. No opt-in screen. Just on by default.

The memory state isn't stored in your chat log either. It lives in a separate data layer that gets prepended to your system prompt at the start of every session. This means deleting a conversation doesn't delete the memories derived from it. They persist until you manually remove them from the Memory Summary.

I didn't know any of this. Most users don't.

This Isn't Hallucination — It's Context Pollution

What I experienced has a name: context pollution.

Traditional hallucinations are the model generating false information. What Dreaming V3 can cause is different — the model generating technically grounded but contextually wrong information. Real data from your history, applied to the wrong situation.

Old health queries. Half-finished debugging sessions. Personal conversations from six months ago. All silently stitching themselves into your active prompts — and the model has no reliable way to know what's still relevant to you now.

When it gets it right, it feels like magic. When it gets it wrong, it corrupts your entire context window.

The Old System Was Better for Privacy

I'll be honest: I strongly prefer the old "Manage Memory" system.

Under the old Saved Memories, you had a notebook you fully controlled. You could see every entry. Add, edit, or delete individual facts. If something was in the list, ChatGPT knew it. If it wasn't, it didn't. The contract was legible.

Under Dreaming V3, that notebook is gone. A background process now decides what's worth remembering on your behalf — inferring things you never explicitly told it, from conversations you may not even remember having.

One power user on the OpenAI Developer Community put it well:

"Under the old system, Saved Memories functioned like a notebook I controlled. Under Dreaming V3, the system now decides what's important on my behalf — and it gets it wrong."

OpenAI acknowledged compute costs for Dreaming were reduced by ~5x to enable free-tier rollout. That's smart business. But from a user-agency perspective, the system became cheaper to run by substituting its judgment for yours.

The Mobile Problem Nobody Is Talking About

This is the part that genuinely frustrated me.

On desktop, the Memory Summary has a clear option: Delete and turn off memory.

On mobile? That option doesn't exist.

📌 Mobile

📌 Desktop Browser

OpenAI's own Memory FAQ quietly notes: "This control is available on the web and rolling out on mobile soon."

No in-product warning. No banner. Mobile users — who make up the majority of ChatGPT's user base — currently have no way to delete their memory summary from their phone. A 2025 survey found 82% of US ChatGPT users consider their conversations sensitive or highly sensitive. Those are largely mobile users.

📌

The Privacy Architecture You Should Understand

A few things most coverage gets wrong or skips:

Deleting a chat ≠ deleting its memories.
The memory layer is separate from your conversation log. Delete a chat containing sensitive content — the memories synthesized from it still exist until you remove them manually from the Memory Summary.

There are two separate privacy toggles — not one.
Most guides treat them as the same switch. They're not.

Settings → Personalization → Memory — controls whether ChatGPT synthesizes and uses your memory profile
Settings → Data Controls → "Improve the model for everyone" — controls whether your conversations are used for model training

📌

These are independent. Turn both off consciously, not just one.

"Don't mention this again" doesn't delete anything.
It only reduces how often something surfaces. The underlying data stays.

How to Take Back Control Right Now

Step 1 — Audit your Memory Summary
Desktop only: Settings → Personalization → Memory → Memory Summary
Read what the system has decided to know about you. You may be surprised.

Step 2 — Turn off memory or delete the summary
Three-dot menu in Memory Summary → Delete and turn off memory
(Desktop only for now — mobile option coming soon)

Step 3 — Turn off model training separately
Settings → Data Controls → "Improve the model for everyone" → OFF

Step 4 — Use Temporary Chat for sensitive conversations
Health questions. Financial situations. API keys. Private work.
Temporary Chat sessions don't use or update memory — the boundary is immediate, not delayed 30 days like the memory toggle.

Step 5 — Revert to legacy saved memories if you prefer control
Settings → Personalization → Memory → tap the small underlined "saved memories" link at the bottom of the screen. Easy to miss, but it's there.

The Bottom Line

Dreaming V3 is technically impressive. OpenAI's internal evaluations show factual recall jumped from 67.9% to 82.8%, and preference adherence improved to 71.3%. For consistent, single-domain usage it's genuinely better.

But the shift from user-controlled memory to AI-synthesized memory isn't a neutral upgrade. It changes the trust architecture of the product. The user no longer decides what the system knows — the system decides for itself, from years of conversations, with a mobile UX that currently blocks the most important control.

When the system blends your health queries with your coding sessions with your personal conversations — and you have no reliable way to separate them — personalization becomes data pollution.

Be intentional about what you share with AI. Not every question needs an AI answer — especially personal ones.

Found this useful? Share it with someone who uses ChatGPT daily and doesn't know this exists.

Full settings guide and step-by-step screenshots → [YOUR LINKEDIN POST LINK]

References

OpenAI — Dreaming: Better memory for a more helpful ChatGPT (June 4, 2026)
OpenAI Help Center — Memory FAQ
OpenAI Developer Community — Dreaming V3 Sacrifices Real Personalization for Compute Savings
TechTimes — ChatGPT Memory Dreaming Update: OpenAI Rewrites Personalization Engine (June 5, 2026)
ACM CHI 2026 — Relational Gains, Privacy Strains: Exploring Users' Perceptions and Experiences with ChatGPT's Memory Feature

About the Author

Shanmugaraj Rajkumar is a BSc Computer Science graduate and Developer focused on Python backend development, FastAPI, and AI/ML engineering. He writes about AI tools, data privacy, and developer experience from a builder's perspective.

🔗 LinkedIn: [https://www.linkedin.com/in/shanmugaraj27]
🐙 GitHub: [https://github.com/Shanmuga-Raj27]

This article is based on personal user-level observation combined with publicly available technical documentation from OpenAI and cited research.

From Prompt to Production: How I Built "Google Stadium" for Google PromptWars 2026

R.Shanmugaraj — Sun, 19 Apr 2026 10:11:38 +0000

Have you ever missed the winning goal of a match because you were stuck in a 30-minute line for a hot dog?

Managing crowds, vendor logistics, and fan experiences inside a massive stadium is a logistical nightmare. For the Google PromptWars: Virtual 2026 hackathon, I set out to solve this problem.

The result is Google Stadium: a real-time, full-stack application that provides seat-direct food delivery, live crowd traffic monitoring, and global stadium communication.

But I didn't build it alone. I built the entire architecture using Google Antigravity and advanced prompt engineering. Here is a look under the hood at how I took this idea from a blank prompt to a live, production-ready cloud application.

🏗️ ** The Tech Stack**
Before diving into the AI process, here is the architecture I decided on to handle real-time stadium data:

-Backend: Python & FastAPI (for high-speed asynchronous processing).

-Real-time Comms: WebSockets (for live global chat and order tracking).

-Database: PostgreSQL managed via SQLAlchemy & Asyncpg.

-Frontend: ReactJS built with Vite, styled with Tailwind CSS.

-Hosting: Render (Decoupled Static Site and Web Service).

🧠 The Secret Weapon: Agile Prompt Engineering
The biggest mistake developers make with AI coding agents is treating them like a vending machine—asking for an entire app in one massive prompt. It almost always results in bloated, broken code.

Instead, I used an Agile Prompting Methodology with Google Antigravity. I treated the AI like a Senior Pair Programmer, breaking the build down into strict, manageable sprints.

1. The Architecture Phase
I didn't let the AI write a single line of React or FastAPI routing until the database was bulletproof. My first prompts were strictly focused on schema design: designing the relationships between Users, Vendors, MenuItems, and Orders. Only once the foundation was solid did we move up the stack.

2. Iterative Component Sprints
Instead of prompting "build the frontend," I scoped prompts tightly:

"Build the Fan Dashboard. It must fetch menu items and allow the user to select a Block, Row, and Seat for delivery."

"Now, build the Vendor Dashboard. It must listen via WebSockets for incoming orders and update their status."

3. Surgical Debugging
AI is fantastic at writing code, but deploying to the cloud is where things get messy. Rather than manually hunting for bugs, I fed terminal errors directly back into Antigravity with strict context.

🐛 ** Squashing Real-World Deployment Bugs**
Building locally is easy; deploying to the cloud is hard. During deployment to Render, I hit two massive roadblocks that tested my prompt engineering skills.

Challenge 1: The Asynchronous Database Trap
My FastAPI backend was built using modern async Python. However, Render automatically provisions databases with a postgres:// URL, which defaults to an old, synchronous driver (psycopg2). The app crashed instantly on boot.

The AI Fix: I prompted Antigravity to inject a safety wrapper in my database.py that intercepts Render's environment variable and dynamically reformats it to postgresql+asyncpg://, allowing my async engine to connect flawlessly.

Challenge 2: The React SPA Routing Black Hole
When I deployed the Vite/React frontend as a Static Site, clicking links worked fine, but if a user hit "Refresh" on the /vendor page, it threw a 404 Error. Render was looking for a literal folder named "vendor" that didn't exist.

The AI Fix: I engineered a prompt to audit the deployment configuration and establish a _redirects fallback file, while simultaneously fixing hardcoded localhost WebSocket URLs to dynamically read import.meta.env.VITE_API_URL.

🚀 The Final Result
By maintaining strict prompt boundaries and utilizing iterative error correction, I successfully deployed a complex, decoupled, full-stack application.

Google Stadium is now live. Fans can order food, vendors can track revenue, and admins can broadcast live messages to the entire stadium.

Working with Google Antigravity taught me that the future of software engineering isn't just about knowing syntax; it’s about system design, understanding the tools, and knowing exactly how to ask the right questions.

🔗 ** Links**
Live Application: https://google-stadium-app.onrender.com/

GitHub Repository & Prompt Vault: [https://github.com/Shanmuga-Raj27/Google-Stadium-]

A huge thank you to Google for hosting PromptWars 2026. Happy coding!