A researcher traced a ChatGPT cookie onto 12 advertiser websites
A token minted inside ChatGPT sets a year-long cookie on openai.com, and OpenAI's ad SDK sends it back from advertiser pages along with hashed contact details.
932 decoded tokens, 936 advertiser pixels, and a cookie OpenAI's own policy files under analytics.
On September 20, 2026, security researcher Jamie Larson published a teardown at Buchodi Threat Intel of a cookie named __obi, arguing that it links a ChatGPT account to browsing activity on advertiser websites. The post documents the mechanism in three steps, with network captures.
Step one: ChatGPT calls its own backend to mint a signed token that expires in 60 seconds. That token binds a random 22-character identifier, called obi, to the account's subject value. Step two: the token is exchanged at bzr.openai.com, which responds by setting a cookie called __obi on the openai.com domain, marked SameSite=None and Secure, with a lifetime of one year. Step three: advertiser pages load OpenAI's SDK from bzrcdn.openai.com, and that script sends __obi back along with the page path and data scraped from the page, including email, phone and name as SHA-256 hashes, plus country, region, city and postal code in the clear.
The SameSite=None flag is the part that matters technically. Larson notes that OpenAI's other cookies are blocked in third-party requests by domain restrictions or SameSite=Lax settings. This one is configured to travel.
The consent flag does not move
Larson decoded 932 sync tokens and reports that every one carried a consent decision of analytics_allowed, including when marketing consent had been refused. OpenAI's published cookie policy lists __obi under Analytics. The scale figures in the post are 936 distinct advertiser pixels across 1,029 hostnames, with twelve commercial sites confirmed transmitting the cookie, among them Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera and SeatGeek. Larson wrote to OpenAI's press and privacy addresses on September 14. OpenAI Support acknowledged receipt and did not answer the questions about classification or consent.
What the captures do not show
The researcher is explicit about the boundary, and it is worth repeating rather than smoothing over. Testing was done on Chrome for Android. Safari and iOS browsers are unaffected because WebKit blocks third-party cookies outright, and desktop Chrome was not tested. Most importantly, Larson did not observe the server-side join between the advertiser data and the account. That the design permits it is demonstrated. That OpenAI performs it is inferred. Independent writeups at CyberSecurityNews and Captain Compliance reproduce the same architecture and stop at the same line.
Why a build studio cares
Half of this story happens on somebody else's marketing site, and that somebody is the kind of client who asks us to add one script tag. A pixel is the single easiest thing to get approved and the single hardest thing to audit later, because it arrives as one line in a tag manager and then decides for itself what to read off the page. The specific detail to take away is that this SDK scrapes form fields and rendered text on the host page, which means the data leaving a checkout page is determined by the vendor's script, not by the contract. When we do an audit pass on a site, the third-party scripts get a network capture, not a reading of the vendor's privacy policy, and the difference between those two things is this entire article.
Next step: read Larson's writeup with the captures, then open your own site in a browser devtools network tab and read what your tags actually send. If you would rather we did that pass, write to us at hello@gattyworks.com.