---
title: "Blok Dev Override Seam — Threat Model & Opt-Out"
description: "Why every published entry checks globalThis.__BLOK_DEV_OVERRIDE__ before falling back to the bundled code, and how to disable it."
source: https://blokeditor.com/docs/dev-override-seam/
lastmod: 2026-08-20
---

Framework JavaScript

Extending & system Dev override seam

# Dev override seam: threat model and opt-out

A development seam every published entry ships with — how it works, why it's safe, and how to remove it from your bundle.

Last updated Aug 20, 2026 [Edit this page on GitHub](https://github.com/JackUait/blok/blob/main/docs/src/components/api/DevOverrideSeamContent.tsx)

## What it is

Every published entry of `@bloklabs/core` first consults `globalThis.__BLOK_DEV_OVERRIDE__` and falls back to the bundled implementation. This is a development seam for Blok's own tooling: it lets a local build be injected into a running app by a browser extension.

## Why it's safe

It is a passive, in-realm read — blok never fetches, evals, or resolves a URL, and the seam never reads localStorage, meta tags, URL parameters, or DOM attributes, so it grants nothing to an attacker who cannot already execute script in your origin. Payloads that are DOM nodes are rejected, which closes DOM clobbering.

## Opt out

If you want the branch gone from your bundle entirely, alias each entry to its implementation module. Use an exact-match (regex) alias — a plain string key like `'@bloklabs/core'` also prefix-matches every subpath — e.g. Vite/Rollup: `resolve: { alias: [{ find: /^@bloklabs\/core$/, replacement: '@bloklabs/core/dist/blok-impl.mjs' }] }`. Each subpath entry (`/tools`, `/full`, …) gets its own pair pointing at its `-impl` module.