Cursor projects need cookie consent the editor never adds

Cursor is an AI-first code editor built by Anysphere that has become a default tool for developers building web apps with Claude and GPT models. Ask it for a marketing site, SaaS dashboard or e-commerce front end and it will produce working Next.js, React or SvelteKit code in minutes. What it almost never produces is a working cookie consent layer. The boilerplate routinely includes Google Analytics 4, Vercel Analytics, PostHog and Meta Pixel snippets that fire on page load, with no banner and no script blocking.

That gap matters. In May 2026, the security firm RedAccess told Axios it had found about 380,000 publicly reachable assets built with AI app tools, around 5,000 of them containing sensitive data, findings the platforms disputed. Consent handling follows the same pattern: the model writes what it has seen most often in training data, and most training data does not include a properly gated consent flow.

What Cursor generates by default

When you prompt Cursor with something like "add Google Analytics to my Next.js site", it will typically insert a <Script> tag in app/layout.tsx that loads gtag.js on every page. There is no check for prior consent. The same pattern applies when you ask for Meta Pixel, LinkedIn Insight Tag, Hotjar, Microsoft Clarity or any of the other trackers developers commonly bolt onto a site.

A typical Cursor-generated Next.js site fires these requests before a visitor sees the first paint:

Vercel's Web Analytics privacy page says it uses no third-party cookies and identifies visitors by a hash created from the incoming request. With nothing stored on the device, the Article 5(3) consent rule may not apply, though the data still needs a lawful basis under the GDPR. The pattern for the other trackers is consistent across frameworks. A Cursor-generated React SPA on Vite will load the same trackers from index.html or a top-level useEffect. SvelteKit projects get them in +layout.svelte. Static Astro sites receive them as global script tags.

Why this breaks EU and UK law

Article 5(3) of the ePrivacy Directive requires informed consent before storing or accessing any information on a user's device that is not strictly necessary for the service they requested. Analytics, advertising, A/B testing and session recording cookies all sit firmly in the non-essential category. Valid consent under GDPR Article 7 must be freely given, specific, informed and unambiguous, which rules out pre-ticked boxes, implied consent from continued browsing and bundled accept-all buttons without an equally prominent reject option.

This is not theoretical. On 1 September 2025 the French CNIL fined SHEIN 150 million euros after inspectors found cookies placed before any banner interaction, and fined Google 325 million euros the same day over Gmail ads and the consent it collected for ad cookies. In November 2025, the CNIL fined Conde Nast 750,000 euros for cookies on vanityfair.fr that fired before the banner appeared. The CNIL sanctioned 21 entities for cookie infringements during 2025 alone.

For a Cursor-built side project, the practical risk is lower than the SHEIN scenario, but the legal exposure is identical. Any complaint to a regulator, any visitor running browser devtools, any automated compliance scanner can flag the same Article 5(3) violation.

The three things Cursor gets wrong

When you ask Cursor to add a cookie banner or handle GDPR consent, the output usually fails in one of three predictable ways.

1. A banner that does not block anything

The most common failure: a banner appears, captures a click, sets a cookie-consent=accepted flag in localStorage and does nothing else. The gtag.js script tag still loads from the global layout, before the React tree even mounts. The banner is decorative.

2. Script blocking without Consent Mode

A better Cursor output will conditionally render the <Script> tag based on a state variable. This blocks the script entirely until consent, which solves the cookie problem. On its own it sends Google no consent signal at all. Blocking Google tags until consent is what Google calls the basic implementation of Google Consent Mode v2, and it is valid as long as the consent states are set when the tags do load. The advanced implementation loads the tags with denied defaults and sends cookieless pings, which gives Google more data for modelling, as Google's consent mode documentation explains. Either way, the Consent Mode calls have to be there for Google Ads measurement in the EEA.

3. No region rules

Cursor-generated banners typically show the same banner to every visitor worldwide. A US visitor in California sees an EU-style opt-in banner, or an EU visitor sees the opt-out flow built for the CCPA. One asks for more than the law requires, the other for less, and both miss the requirements of the layered privacy laws now in force across 19 US states, Brazil, Canada and the UK.

A working pattern for Cursor-generated Next.js apps

The fix has three parts: a banner that captures a granular choice, a script gate that respects that choice, and a Consent Mode bridge for Google services. The cleanest way to retrofit this into a Cursor project is to introduce it as a single client component that wraps the application, then prompt Cursor to refactor existing tracker calls.

The high-level shape of the code:

• A ConsentProvider client component holding state for the four Consent Mode v2 keys plus any extra categories.

• A gtag('consent', 'default', {...}) call that fires before any tag loads, defaulting everything to 'denied' for EU traffic.

• A geo-detection step, in middleware or in a CMP, that applies the rule you set for each region: opt-in with everything denied by default for the EU and the UK, and an opt-out of sale and sharing that honours Global Privacy Control for US states with privacy laws.

• A banner that calls gtag('consent', 'update', {...}) after the user chooses, then unblocks any hard-gated scripts.

• A consent log endpoint storing the timestamp, region, banner version and choice for audit.

Trying to get Cursor to write this from scratch tends to produce one of the broken patterns above. A more reliable approach is to drop in a managed CMP script before any tracker, then ask Cursor to wire the existing trackers behind the CMP's consent events. With Kukie.io, the script goes into app/layout.tsx through next/script with the beforeInteractive strategy, and the page learns about each choice from the cc:consent-updated event on document, whose detail.categories lists the accepted category slugs:

document.addEventListener("cc:consent-updated", (event) => {
  if (event.detail.categories.includes("analytics")) {
    // Initialise Google Analytics or PostHog here.
  }
});

Cursor compared with other AI coding tools

Cursor sits in a category that includes Replit, Bolt.new, Lovable, Base44 and v0. The consent gaps differ.

The key difference: with a Cursor project you own the source and the hosting, so you control what loads when. With a hosted AI website builder you are limited to whatever consent surface the platform exposes. Cursor's flexibility is also its trap.

Auditing what Cursor actually shipped

Before adding a banner, find out what is firing on your site today. The fastest path is a third-party scan, since Cursor has likely added trackers in places you do not remember approving. A free cookie scan lists every cookie set, the script that set it and the request domain.

For a manual check, open Chrome DevTools, switch to Application then Cookies, and reload the page in a private window. Every cookie that appears before you click anything is a cookie you set without consent. Common surprises in Cursor-generated codebases:

• Vercel Analytics enabled through @vercel/analytics/react in app/layout.tsx: cookieless by Vercel's account, but worth naming in your privacy policy.

• PostHog autocapture initialised in a top-level useEffect with no consent check.

• A self-hosted Plausible or Umami script that the developer assumed needed nothing: check what it stores, and name it in the privacy policy either way.

• YouTube embeds loading youtube.com rather than youtube-nocookie.com, dropping VISITOR_INFO1_LIVE on first paint.

What to prompt Cursor for

Cursor is good at refactoring once the architecture is clear. Prompts that produce useful output:

Good: "Find every place in this codebase where a third-party script tag is added or a tracking SDK is initialised. List each one with the file path and whether it currently has a consent check. Do not modify any code yet."

Good: "Move the Google Analytics initialisation into a listener for the cc:consent-updated event on document, and run it only when event.detail.categories includes analytics. For plain script tags, set type="text/plain" and data-cc-category="analytics" instead."

Avoid: "Sort out GDPR for this site." This prompt is too broad and tends to produce broken patterns. Consent is a set of decisions about jurisdiction, categories and lawful basis, not a function the model can call.

Cursor and cookie consent: short answers

Ship a Cursor project with its trackers gated

Cursor will keep producing code that ignores cookie consent until its training data shifts, which means responsibility sits with the developer pushing to production. A managed CMP closes the gap without re-prompting the model to rewrite the same files. Kukie.io scans Cursor-generated sites, categorises every cookie it finds, blocks non-essential scripts until consent, ships Consent Mode v2 signals to Google, and logs every consent decision for audit.

Start free