DEV Community: Usamah Klair

Raw Markdown Syntax Surfacing in Chat Search Previews - ChatGPT

Usamah Klair — Tue, 08 Sep 2026 18:16:22 +0000

Search preview snippets display raw markdown syntax (**, #, ##, ---,``) instead of rendered text, while the same content renders correctly inside the actual conversation.

Open any chat containing markdown-formatted text (bold, headings, dividers, inline code).
Use the chat search feature.
The preview snippet shows raw syntax tokens, unrendered. See the screenshots below
Opening the same chat shows the content rendered correctly, confirming the content itself is fine, only this display path is affected.

Why this matters

Search is a high-intent moment, people are trying to locate something specific. Surfacing raw syntax at that moment adds friction, especially for non-technical users who won’t recognize **, --- or ## as formatting rather than a bug.

Suggested fix

Either render markdown in preview snippets to match the conversation view, or strip the syntax tokens so previews show plain readable text. For a compact row, stripping is probably the simpler, more scannable option.

Another Example.

Gmail Username Change: What Happens to Your Third-Party Accounts

Usamah Klair — Tue, 08 Sep 2026 17:56:29 +0000

On March 31, 2026, Google announced that users can now change their Gmail username for the first time. A feature millions of people had been waiting for. Sundar Pichai shared the news publicly, and the response was overwhelmingly positive.
But while everyone was celebrating, I was asking a different question.

I raised my first flag: when you change your Gmail username, does mail sent to the old address still reach you? Years of institutions only know you by that old email, banks, universities, services you signed up for years ago and forgot about. The question sounds simple until you realize you can't notify all of them.

My second flag is where it got serious.

For most people, a Gmail address is not just an inbox. It is their identity across the internet. Every time someone tapped "Sign in with Google" instead of creating a password, on Spotify, Canva, Notion, Airbnb, hundreds of other platforms, that Gmail address became the key those platforms used to recognize them. Years of account history, saved data, purchases, preferences, all tied to that one address.

So what happens to all of that when the address changes?

Those platforms are not inside Google's ecosystem. They built their own databases. They stored your identity their own way. Google can update its own systems instantly, but it cannot reach into thousands of independent platforms and update their records at the same time.

That gap is the problem.

The Explanation

Here is what happens to a user after changing their Gmail username. They come back weeks later and tap "Sign in with Google." Google authenticates them successfully and their account is fine. But when Google passes their identity to that platform, it sends the new email address. The platform looks it up. Finds nothing. As far as that system is concerned, this person has never existed.

No warning. No explanation. A duplicate empty account gets created. In the worst case, they are locked out entirely, losing years of data, history, and access without understanding why.

Why does this happen to some platforms and not others? It comes down to a decision made long before you ever changed your username.

When a platform integrates "Sign in with Google," it has to decide how it will identify returning users. Many platforms took the simpler path: they stored your email address as your identifier. It was easier to build, easier to read, easier to manage. And for years it worked perfectly because Gmail addresses never changed.

Until now.

The right way to do it is to use something Google calls a Subject ID, a permanent internal identifier tied to your Google account. It never changes. Regardless of what happens to your email address, your Subject ID stays the same forever. Platforms built this way are completely safe. A username change is invisible to them.

Google Confirmation

I raised both flags publicly under Sundar Pichai's announcement. The first on April 1st, the second on April 2nd. That same day, Google's developer team published an official article titled "Supporting Google Account username change in your app," confirming exactly what I had identified: platforms using email address as the primary identifier may fail to recognize users after a username change, potentially resulting in duplicate accounts or complete loss of access to existing data.

The first flag, about email delivery, Google's feature design had already solved. The old address stays active as an alias, both addresses point to the same inbox, nothing gets lost.

The second one, the identity risk across third-party platforms, Google confirmed as a real and ongoing problem.

Supporting Google Account username change in your app →

What You Should Do

If you're considering changing your Gmail username, don't do it without taking these steps first.

Before switching, open your Google Account, go to Security, and find "Your connections to third-party apps & services." This gives you the full list of every platform tied to your Google identity. Go through it. For anything important such as banking, productivity tools, subscriptions, anything with years of history behind it, log in and confirm your access now, while your current address is still active.

After switching, go back to those same platforms one by one and manually update your email in their account settings, wherever that option exists. Don't wait for a failed sign-in to find out which ones were vulnerable.

For platforms with no manual update option, reach out to their support before you need to. Keep a record, a screenshot, an email, anything that shows the account was yours.

The feature is available today. The risk is real today. A few hours of preparation now is the difference between a smooth transition and losing years of access you can't easily get back.

Closing Thought

Google built a genuinely useful feature. Giving people the option to change an address they've outgrown, tied to an old name, an old version of themselves. This is a good thing to add.

But identity-level features carry a different kind of responsibility than most. For years, thousands of platforms built their systems around the assumption that a Gmail address doesn't change, without ever really questioning it. That assumption doesn't hold anymore, and most of those platforms don't know it yet. Most users don't either.

Google told developers. But developers aren't the ones clicking "change username" on a random Tuesday because they finally can.

That's really the gap here. The people actually taking the risk are the ones least likely to know it exists.

Visual references in this article are adapted from Google Developers blog, Source: developers.googleblog.com

Unrendered Markdown in the Ask ChatGPT Reply feature

Usamah Klair — Sat, 29 Aug 2026 10:45:09 +0000

Summary
Ask ChatGPT reply feature, where selecting text from a response creates a reference chip above the input box, displays raw markdown syntax instead of rendered text. Bold markers, headers, table pipes, and dividers all show up as literal characters (*, #, |, -, =) rather than the clean formatting visible in the conversation itself. This is confirmed across two distinct content types: divider-separated text and full markdown tables.

Problem:
When you select part of a response and use the Ask ChatGPT feature, the chip that appears above the input box shows the raw markdown source of that selection such as asterisks, hash marks, table pipes, dividers, etc. (*, -, =, |, #), instead of the clean text you just read in the conversation.

In any response with markdown formatting (a heading, bold text, a table, or a — divider), select a span that includes that formatting.
Trigger the Ask ChatGPT action.
The chip above the input box renders the literal markdown characters instead of formatted text.
Confirmed with two distinct cases: a divider-separated text block and a full markdown table with headers and bold values.

Why this matters:
Users need to see what they’re about to reply to or ask about. That only works if the chip looks like the thing it was copied from. Right now it doesn’t - a bolded table cell becomes text, a section header becomes ### text, and other symbols like ===, ***, | , and — show up unrendered too. For anything table-shaped, the reply chip turns into a wall of pipes and dashes that’s genuinely hard to parse. The feature is supposed to reduce ambiguity about what’s being referenced; instead it introduces a confusion moment.

Suggested fix:
Have the chip render through the same markdown pass as the conversation view, or fall back to a stripped plain-text version if a lightweight render isn’t feasible in that component.