Windows CEF builds ship 13 Chromium files twice (341 MB of an 836 MB install)

With bundleCEF: true on Windows, the packaged app contains 13 Chromium files twice: once in bin/ and again in bin/cef/. The copies are byte-identical (same SHA-256) and add 341,077,751 bytes, 41% of the unpacked app (835,899,353 bytes). Removing one copy of each leaves an app that still starts and renders with CEF.

Versions: Electrobun 2.0.4 (Hutch 0.28.1, as downloaded by electrobun build), Windows 11 x64, Bun main process.

Reproduction

electrobun.config.ts:

import type { ElectrobunConfig } from "electrobun";

export default {
  app: { name: "CefDup", identifier: "com.example.cefdup", version: "1.0.0" },
  build: {
    bun: { entrypoint: "src/bun/index.ts" },
    win: { bundleCEF: true, defaultRenderer: "cef" },
  },
} satisfies ElectrobunConfig;

src/bun/index.ts:

import { BrowserWindow } from "electrobun/main";
new BrowserWindow({ title: "CefDup", url: "https://example.com" });

bun add -d electrobun@2.0.4
bunx electrobun build --env=stable

Then list the files in build/stable-win-x64/CefDup/Resources/*.tar.zst, or install the app and look in %LOCALAPPDATA%\com.example.cefdup\stable\app\bin.

Building exactly this project gives the same 13 duplicated files and 341,077,751 duplicated bytes (835,896,831 bytes unpacked).

Expected: each Chromium file appears once.

Actual: these 13 files appear in both bin/ and bin/cef/, with identical contents:

The installer also leaves the extracted package in a self-extraction folder beside the installed app, so the 341 MB lands on disk twice after install. The setup zip was 290 MB for a one-window app.

Where the extra copy seems to come from

• The release asset electrobun-cef-win-x64.tar.gz (v2.0.4) has these files only under cef/, so the build step adds the copies in bin/.
• At runtime, nativeWrapper.cpp checks for libcef.dll and icudtl.dat next to the executable (isCEFAvailable) and points resources_dir_path at bin\cef (around line 6972). So the DLLs are needed in bin/ and the .pak files in bin/cef/. The other copy of each looks unused.
• The extractor's fixCefSymlinks looks like the Linux answer to the same layout. It also runs on Windows, where it tries to link libcef.so and logs Warning: Could not create symlink for libcef.so: error.PermissionDenied.

Check that one copy is unused

In the installed app I deleted the nine DLLs, icudtl.dat and v8_context_snapshot.bin from bin/cef/, and both .pak files from bin/, removing 341,077,751 bytes. The app still started with CEF (user agent Chrome/147.0.0.0) and rendered a 2,000-row test page identically on two launches.

What I did not check: whether some code path, such as GPU fallback, devtools or another locale, reads a deleted copy. Also not checked: whether macOS or Linux builds have the same duplication.