When an App Says “Forget”, What Would It Take to Believe It?

I tried to make chat history more convenient. Then I met the software equivalent of someone who keeps screenshots.

“Forget what I just told you.”

A reasonable request. Five words. No one expects to need a diagram.

Imagine deleting your old address from an assistant, closing your laptop, and returning later to find it remembered again.

You've moved out but your software renewed the tenancy.

There doesn’t have to be anything inteligent—or malicious—behind this. One part of the application might simply be working with an older copy of your information.

Unfortunately, it also has permission to save.

I ran into this class of problem while working on a proposed change to VS Code’s chat history. I wanted conversations to be available across workspaces: the different project folders open in the editor.

A convenient feature, I thought.

The review comments had prepared a presentation.

I wanted my chats to follow me around

My VS Code pull request attempted to move local chat history towards storage shared across a user profile.

The idea was straightforward: open another project, still find your conversations.

But once multiple windows can access the same history, they can also have competing ideas about what should happen to it.

One Copilot review comment identified a possible sequence: a conversation is open in two windows; one window deletes it; the other still holds an older copy. When that second window saves or shuts down, it can recreate the deleted entry.

So the conversation could survive deletion through the heroic efforts of a window nobody asked.

A later comment raised another version: an update already waiting to be saved could overwrite the record marking the conversation as deleted.

These were findings on my proposed code, not claims about a shipped VS Code defect. I eventually closed the PR while struggling through the reviews.

I would love to say every review made the solution obvious. The PR description, in which I admit I’m struggling, offers a less cinematic account.

But the problem stayed interesting:

What does “deleted” mean when another part of the application still thinks it has something worth saving?

Your second window has the screenshot

Think of deleting a message from your own chat history. Your friend may still have a copy.

You have removed it from your phone. Your friend has filed it under Things To Bring Up At Your Wedding.

Two application windows can behave similarly, except the second window may be allowed to put its copy back into shared storage.

Here is a deliberately tiny JavaScript example:

let stored = { address: "14 Example Road" };

// Another window loads its own copy.
const otherWindow = { ...stored };

// You delete the saved address.
stored = null;

// Later, the other window saves its older copy.
stored = { ...otherWindow };

console.log(stored.address); // "14 Example Road"

No AI. No elaborate infrastructure. Just an old copy arriving after a deletion.

The delete operation executed successfully. Then the later save recreated what it had removed.

If you only checked immediately after deletion, everything would look fine. The problem appears when the second window gets its turn.

An offline device reconnecting later creates a similar design question. It has information the server no longer has. Should it restore that information?

Perhaps the server never received it. Perhaps the user deliberately deleted it.

Without a record of what happened, the device cannot reliably distinguish the two. It is trying to help with the confidence of someone tidying your desk into a system only they understand.

To forget something, you may need to remember its deletion

One established approach is a tombstone: a small record saying that an item was deleted.

Yes, databases have tombstones. We gave the data a funeral because it would not stop coming back.

Instead of retaining the address, a simplified system might retain:

{
  id: "memory-42",
  revision: 2,
  deleted: true
}

The id identifies the item. The revision identifies its version. The deletion flag records what happened without keeping the address in this marker.

An older window trying to save revision 1 can now be refused. Its information predates the deletion.

This is an existing database technique. CouchDB, for example, documents deletion markers so deletions can propagate between databases.

But a marker only helps if the relevant write paths respect it.

One comment on my PR described a pending update overwriting a deletion marker. In other words, the system could have written down “this was deleted” and still let an older operation replace that decision.

The tombstone was there. Someone parked on it.

A robust implementation needs to check whether a write is still permitted when it commits. The check and write must happen as one protected operation. Otherwise, something can change between checking and saving.

There also needs to be a deliberate policy for recreation. A user choosing to enter the address again is different from an old window restoring it without asking.

“Remember this again” and “I found this behind the sofa” should not receive the same authority.

An assistant can keep the fact after you delete the sentence

Now add an assistant that creates memories or summaries.

Suppose you say:

“I live at 14 Example Road. Remember it for deliveries.”

Depending on the application’s design, that could produce several records:

Record	What it might contain
Conversation	Your original sentence
Saved memory	A structured home address
Conversation summary	A shorter account that includes the address
Active request	A copy already retrieved for an answer

This is a hypothetical architecture, not a claim about a particular assistant.

The important detail is that the address now has several places to live. It has achieved a more diversified property portfolio than most of us.

Deleting the saved-memory record would not automatically remove the address from the other places.

If the assistant later reads the conversation and extracts the address again, it could recreate the memory you removed. A feature designed to remember useful information has just become extremely committed to an outdated instruction.

The user says “forget”. The memory system says “look what I found”.

This is where provenance helps: recording where a memory or summary came from.

If a saved fact was derived from a particular message, that relationship gives the application a starting point for deciding which other records need removing or rebuilding.

It is not a complete solution. A summary may combine several sources. The same fact may appear independently in another conversation.

The user’s intention also matters. Deleting a saved address might mean “don’t use this for deliveries anymore”. It might mean “remove every stored occurrence”. Those requests have different scopes, and the interface needs to explain which one it can fulfil.

A tiny bin icon is doing a lot of contract negotiation here.

Your assistant may already be halfway through saying it

There is another awkward sequence:

1. The assistant retrieves your address.
2. You delete the address.
3. The assistant finishes the answer it had already started.

The storage could be correct at step three. The answer could still contain the address.

This is the software version of saying “don’t announce that” after someone has switched on the microphone.

Controlling future saves does not settle this problem. The application may also need to cancel affected work or check that its information is still permitted before displaying the result.

For our hypothetical assistant, I would test whether forgetting survives:

• An older window saving its state.
• An offline client reconnecting.
• A queued memory update finishing.
• A summary being regenerated.
• An answer already in progress.

The useful question in each test is specific: can this operation restore or reveal information after the deletion it should respect?

Passing those checks establishes particular behaviours. It does not prove that every backup, log or external service has erased every copy. Those require their own handling and an accurate explanation of what remains.

A green test suite is reassuring. It still cannot testify about systems you never tested.

“Forgotten” is a bigger promise than “removed from this list”

By this point, “Delete” has become a surprisingly ambitious label for such a small button.

As a user, I don’t want a guided tour of the database. I clicked the bin icon. I was hoping to get on with my afternoon.

But I would rather see:

“Removed from saved memory. It still appears in this conversation.”

than a confident “Forgotten!” followed by my old address making a guest appearance next Tuesday.

That message gives me something useful: a clear account of what changed and what remains. I can decide whether I want to remove the conversation too.

The engineering underneath still has to honour that choice. Older windows, queued updates and reconnecting devices need to respect the deletion, even if they missed the original announcement.

That is the part I keep coming back to: forgetting has a future tense. Removing information now is only part of the job. The system also has to prevent its own unfinished work from restoring it later.

Otherwise, “I’ve forgotten that” is just something the app said before its other window returned from lunch.