Vibe-coded apps almost never ship with a working cookie consent banner, yet they rarely ship with zero cookies either. The gap between those two facts is where the GDPR risk sits. What differs from one AI app builder to the next is not whether the problem exists but which layer of the stack puts the trackers there: the code the model scaffolds into your app, the platform that hosts it, the content delivery network in front of it, or the preview URL you shared before launch. Pin down the layer and you know exactly what to audit.
The builders people actually ship with in 2026 fall into a few architectural groups, and their default cookie behaviour splits along those lines rather than along brand reputation. A prompt-to-app builder with managed hosting leaks cookies differently from a design-to-code tool, an in-editor assistant, or a platform-native SDK.
Why Don't AI App Builders Add Cookie Consent by Default?
AI app builders optimise for a working app, not a compliant one. You prompt for a landing page with analytics and a sign-up form, and the model delivers exactly that, including the analytics snippet, the embedded video, and the web font, without ever pausing to ask whether any of it needs consent. Consent is a legal requirement rather than a feature request, so it falls outside what the prompt rewards. The baseline it skips is specific: the ePrivacy Directive requires consent before non-essential cookies are stored, and the GDPR sets the bar for what counts as valid consent. Neither is satisfied by an app that simply works.
That much is common across every builder. The useful question is the next one.
Where Do the Cookies Actually Come From in a Vibe-Coded App?
In a vibe-coded app, cookies and similar storage come from four distinct layers, and each carries a different consent obligation. The scaffold layer is the code the AI writes into your project, meaning third-party analytics, advertising pixels, embeds and fonts, and it is almost always the layer that triggers consent. The managed-host layer is the analytics the hosting platform bundles in, which on some platforms is cookieless and on others is not. The runtime layer is the content delivery network and server in front of the app, which sets functional cookies for security and routing. The preview layer is the shareable URL the builder hands you before launch, which can carry the platform's own tracking. Most teams audit the first layer and forget the other three.
| Layer | Typical cookies or storage | Consent treatment |
|---|---|---|
| Scaffold (AI-generated code) | _ga, _gid, _fbp, Clarity, Hotjar, YouTube embeds | Consent required before they load |
| Managed-host analytics | Cookieless hash (Vercel, Cloudflare) or vendor cookies | None if cookieless; consent if cookies are set |
| Runtime / CDN | __cf_bm, cf_clearance, session and auth cookies | Usually strictly necessary, but must be disclosed |
| Preview / share URL | Platform analytics on the preview domain | Outside your control; never treat as production |
Cookie names like _ga for Google Analytics and _fbp for the Meta Pixel are the obvious offenders, and they sit squarely in the scaffold layer. The subtler exposure is the runtime layer, where a single cookie can be both actually necessary and still legally require a line in your cookie policy.
How Does Each Platform Behave, Grouped by Type?
Group the builders by how they produce and run an app and the cookie picture clears up fast. Prompt-to-app builders with managed hosting bundle the app and its runtime together, so trackers can come from both the scaffold and the host. Design-to-code tools hand you a component or a deployment whose cookie profile depends on where it lands. In-editor assistants write into a project you already control and add nothing at runtime, which puts the entire obligation on you. Platform-native generators run on a specific edge or mobile runtime with its own storage behaviour. The fix is similar across all four groups, but the place you look for the leak is not.
Prompt-to-App Builders With Managed Hosting
Lovable, Bolt, Replit, Base44 and Firebase Studio all turn a prompt into a deployed app on infrastructure they manage. By default none of them inserts a consent banner, and the apps they generate commonly wire in Google Analytics, a Meta Pixel, or a chat widget because those are the snippets the model has seen most often. Base44 is a particular case after its acquisition by Wix, since its hosting and analytics defaults increasingly inherit the Wix platform rather than a neutral baseline. Firebase Studio deploys onto Google infrastructure, which makes Google's own analytics the path of least resistance. In each case the scaffold layer is where the consent-triggering cookies live, and the host adds session or routing cookies on top.
Design-to-Code and Managed Front-End Hosting
v0 by Vercel sits in a different category. It generates interface code you deploy, typically onto Vercel, and Vercel's built-in Web Analytics is cookieless by design. A bare v0 app on Vercel with nothing but the platform's own analytics can run without a consent banner. That exemption is narrow and easy to lose, which the next section unpacks.
In-Editor AI Assistants
Cursor and Windsurf do not host anything. They write code into a project you already own and deploy yourself, so they add no runtime layer of their own. Whatever cookies your app sets are the ones you or the assistant wrote into it, which means the consent obligation is entirely yours and entirely predictable. The risk here is not a hidden host tracker but an analytics library the assistant happily added when you asked for usage tracking.
Platform-Native and Mobile Generators
a0.dev targets Expo and React Native, so its output is a mobile app where the relevant question is the operating system's tracking permission rather than a web cookie banner, though any embedded web views bring cookie rules back into scope. Cloudflare VibeSDK generates apps that run on Cloudflare Workers, where the runtime layer sets functional cookies such as __cf_bm for bot management. These are different runtimes with different default storage, which is exactly why a single answer to does it need a banner fails across the group.
Is the v0 and Vercel No-Cookies Claim Actually True?
Yes, but only for the bare scaffold plus the host's own analytics, and almost no real app stays that bare. Vercel Web Analytics identifies visitors with a hash generated from the incoming request, stores no cookies, and discards the value after 24 hours, so it does not require consent. Cloudflare's own Web Analytics works the same cookieless way. The exemption survives exactly until someone, whether you, a teammate, or the AI on the next prompt, adds Google Analytics 4, a Meta Pixel, or a heatmap tool. The moment a real tracking cookie lands, the app needs Google Consent Mode v2 wiring and a banner that blocks those scripts until consent. Treating the cookieless host analytics as proof the whole app is exempt is the most common mistake in this category.
What Has Enforcement Actually Punished?
Regulators have fined precisely the behaviour a default vibe-coded app exhibits: cookies that fire on page load before any choice, and refusal buttons that do not stop them. France's data protection authority, the CNIL, issued 83 sanctions totalling around EUR 486.8 million in its 2025 enforcement, with cookie and tracker violations making up the bulk. In September 2025 it fined Google EUR 325 million over cookie consent and advertising practices, and fined SHEIN's Irish subsidiary EUR 150 million after finding advertising cookies dropped the moment a user landed on the site, with tracking that continued even after the visitor clicked Reject all. In November 2025 it fined American Express Carte France EUR 1.5 million for cookies set before any choice and read after consent was withdrawn.
None of those companies used an AI builder. The failure mode they were fined for, storage before consent and refusal that does not work, is the exact default an unmodified vibe-coded app ships with. The full set of recent cookie consent fines shows the same pattern repeating across regulators.
Does the EU Digital Omnibus Change the Picture for AI-Built Apps?
Not in any way you can build on today. The Digital Omnibus, proposed by the European Commission in November 2025, would move cookie rules under the GDPR, add a mandatory single-click reject, stop sites re-asking for six months after a refusal, and exempt genuinely low-risk uses such as aggregate visitor counting from the banner requirement. The headline simplification, a browser-level signal that would have let devices express tracking preferences automatically under proposed Article 88b, was removed from the Council's negotiating position in June 2026 after lobbying, and the Parliament has not finalised its stance. The package is still a proposal, the earliest realistic effect is late 2026 or 2027, and consent before non-essential storage remains the rule throughout. An app generated today still needs a working banner, and a future where some banners disappear will not retroactively fix an app that tracked visitors without consent in the meantime.
How Do You Make a Vibe-Coded App Compliant, Layer by Layer?
Fixing a vibe-coded app means closing each layer in turn rather than dropping in a single banner and hoping. Start with the scaffold layer: identify every analytics and marketing script the build added, and block them until the visitor consents, wiring Google tags through Consent Mode v2 so they hold by default. Keep the managed-host analytics cookieless where the platform offers it, or gate it behind the same consent state if it sets cookies. Disclose the runtime layer in full, since functional cookies such as __cf_bm are usually strictly necessary and exempt from consent, yet they still belong in your cookie policy. Treat preview URLs as throwaway, never as a compliance reference. Then scan the deployed app, because the only reliable inventory is the one taken against the live site, not the prompt.
Responsibility does not shift to the model. Whoever operates the deployed site is the data controller and answers for its cookies, regardless of which builder generated the code. If the app serves visitors outside the EU as well, the same logic extends to the other regimes covered under global compliance, each with its own consent or opt-out model.
Frequently Asked Questions
Do Lovable and Bolt add a cookie consent banner automatically?
No. Both generate the app you describe, including any analytics or pixel scripts, but neither inserts a consent banner or blocks those scripts until the visitor agrees. You have to add consent management yourself before launching to EU visitors.
Does a v0 or Vercel app need a cookie banner?
Only if it sets non-essential cookies. Vercel's built-in Web Analytics is cookieless and needs no banner, but the moment you or the AI add Google Analytics, a Meta Pixel, or a heatmap tool, a consent banner becomes mandatory.
Are Cloudflare cookies like __cf_bm subject to consent?
Cloudflare classifies __cf_bm and similar bot-management and load-balancing cookies as strictly necessary, which generally exempts them from prior consent. They still need to be listed in your cookie policy, and disclosure is required in some jurisdictions.
Who is liable when an AI builder generates non-compliant cookie code?
The operator of the live website is the data controller and carries the legal responsibility, not the AI builder or the model that wrote the code. Regulators act against the site setting the cookies, regardless of how the code was produced.
Will the EU Digital Omnibus remove cookie banners for AI-built apps?
Not yet, and not for tracking cookies. The proposal would exempt some low-risk uses and add a single-click reject, but it is still in negotiation, the browser-signal element was dropped in June 2026, and consent before non-essential storage stays the rule into 2027.
How do I find out what cookies my vibe-coded app sets?
Run a cookie scan against the deployed URL rather than reading the generated code, since the live site reveals trackers that load from third-party scripts and embeds. Browser developer tools or a cookie scanner will list every cookie set on first load.
Scan Your AI-Built App Before You Launch
If you generated an app with a vibe-coding tool and have not checked what it sets on first load, start with a scan. Kukie.io detects first-party and third-party cookies, groups them by category, and blocks non-essential scripts until a visitor consents, across whichever platform built the app.
