✅ Quick Summary

Push44 uses a MutationObserver that watches the document for any div with zIndex 2147483647 and position fixed — the badge's unique fingerprint. When one appears, it's removed immediately. The badge.js script's internal re-insert guard (a boolean flag set to true after first render) ensures that once the badge is removed this way, it won't re-insert during the same page session.

The Problem

The bolt.new badge is resilient by design. It uses Shadow DOM to prevent CSS from reaching its internals, and zIndex 2147483647 to sit above all other content. Naive approaches like display:none or setting zIndex on the parent don't work because the badge re-inserts itself if removed incorrectly.

How Push44 Solves It

Push44 uses a MutationObserver that watches the document for any div with zIndex 2147483647 and position fixed — the badge's unique fingerprint. When one appears, it's removed immediately. The badge.js script's internal re-insert guard (a boolean flag set to true after first render) ensures that once the badge is removed this way, it won't re-insert during the same page session.

Step-by-Step Guide

1

Understand the badge structure

bolt.new's badge.js creates a <div> element with style.zIndex = '2147483647' and style.position = 'fixed'. Inside this div is a Shadow DOM containing the actual badge markup. The Shadow DOM means innerHTML is always empty from the outside — you can't detect the badge by its contents.

💡 Pro Tip
Never try to detect the badge by its innerHTML or class names. Always use the zIndex fingerprint.
2

Why CSS hiding fails

Setting display:none on the badge container doesn't prevent badge.js from re-inserting it. The script checks whether the badge element exists in the DOM and re-creates it if missing. You need to remove the element in a way that satisfies the script's internal guard flag.

💡 Pro Tip
The badge.js script sets an internal boolean flag when the badge first renders. Once set, the script won't re-insert the badge even if you remove the element.
3

The MutationObserver approach

Push44 prepends a MutationObserver to your JS bundle that watches for added nodes. When it detects a div with zIndex 2147483647 and position fixed, it removes it before badge.js can complete its initialization. Additional setTimeout sweeps at 500ms, 1700ms, and 3000ms catch any deferred insertions.

💡 Pro Tip
The three setTimeout sweeps are insurance against race conditions where badge.js initializes after the initial MutationObserver fires.
4

Re-deploy the modified bundle

Push44 downloads your live JS bundle, prepends the blocker, builds a valid ZIP with correct asset paths, uploads to bolt.new's staging, and promotes to live. The entire process uses bolt.new's own deployment API.

💡 Pro Tip
The ZIP must have the correct structure (assets/ directory, index.html, favicon.svg) or bolt.new will reject the upload.

Pro Tips

  • The badge blocker is prepended before your app code, so it runs first
  • The MutationObserver is set up synchronously — it's watching before any app code runs
  • Hard-refresh after removal to bypass CDN cache

Common Mistakes to Avoid

⚠️ Watch Out For
  • Using CSS to hide the badge (it re-inserts)
  • Using innerHTML to detect the badge (Shadow DOM blocks this)
  • Forgetting to re-run after a new bolt.new editor deployment

Ready to Export?

Push44 is free, open source, and takes under 2 minutes to set up.

Start Exporting Now → View on GitHub

Frequently Asked Questions

Why doesn't CSS display:none work?
badge.js detects when its element is removed from the DOM and re-inserts it. CSS only hides it visually; the element still exists and the script still runs.
Is the MutationObserver approach reliable?
Yes. Because it's prepended before your app code, it's watching before badge.js even has a chance to run. The setTimeout sweeps add extra insurance.
Does the badge blocker slow down my app?
Negligibly. The MutationObserver is non-blocking and the entire blocker script is under 500 bytes minified.