Bug Report: Freebuff CLI cannot start on Windows — TUI entry point appears to be a packaged test script

[shangli0116-arch]

Bug Report: Freebuff CLI cannot start on Windows — TUI entry point appears to be a packaged test script

Product: Freebuff CLI (freebuff)
Affected platforms: Windows (win32-x64, and win32-x64-baseline)
Severity: High — the core interactive TUI is completely unusable on Windows
Affected versions: Verified broken in 0.0.130, 0.0.135, 0.0.136, 0.0.137 (latest). Likely affects a wider range.

---

Summary

Running freebuff on Windows (with no arguments, which should start the interactive terminal UI) immediately prints:

Usage: node test-bootstrap-caching.mjs PLUGIN_PATH present|missing

...and exits. The interactive TUI never starts. This is not environment-specific: it reproduces on a fresh install with the binary downloaded directly from the official release CDN, across multiple versions, and on both the standard and baseline Windows builds.

The output strongly suggests the Windows production binary was accidentally built from / bundled with an internal test script (test-bootstrap-caching.mjs) instead of the real CLI entry point.

---

Steps to reproduce

1. Install and run

npm install -g freebuff
freebuff

Expected: the interactive coding-agent TUI starts.

Actual output (in PowerShell, CMD, and Git Bash):

PS E:\atomcode> freebuff
Usage: node test-bootstrap-caching.mjs PLUGIN_PATH present|missing
PS E:\atomcode>

2. Run the downloaded binary directly (bypasses the npm launcher)

"C:\Users\<user>\.config\manicode\freebuff.exe"

Same output:

Usage: node test-bootstrap-caching.mjs PLUGIN_PATH present|missing

---

Evidence that this is a broken release artifact, not a user-environment issue

A. Fresh download from the official CDN reproduces the bug

The binary is fetched by the launcher from:

https://codebuff.com/api/releases/download/<version>/freebuff-win32-x64.tar.gz

Downloading that tarball manually, extracting, and running freebuff.exe directly reproduces the exact same error. The extracted exe is byte-identical to the locally cached one (123,627,784 bytes), confirming the broken binary is what is distributed to all users.

B. Reproduces across multiple versions

Tested all of the following and got the identical error:

• 0.0.137 — freebuff-win32-x64.tar.gz
• 0.0.136 — freebuff-win32-x64.tar.gz
• 0.0.135 — freebuff-win32-x64.tar.gz
• 0.0.130 — freebuff-win32-x64.tar.gz
• 0.0.137 — freebuff-win32-x64-baseline.tar.gz (baseline build for older CPUs)

C. Not caused by Windows 11 or a non-ASCII username

Environment under test: Windows 11 25H2 (build 10.0.26200.8875), username contains non-ASCII characters (Chinese).

To rule out locale/path issues, the exe was copied to a pure-ASCII path (C:\fb_ascii_test\freebuff.exe) and executed there. Same error. This is a binary-level defect that will affect any Windows machine.

D. The npm package and CLI framework are fine — only the TUI is broken

The following all work correctly:

• freebuff --help ✅
• freebuff --version → 0.0.137 ✅
• freebuff -v → 0.0.137 ✅
• freebuff login ✅ (prints login URL and waits)

Only the no-argument TUI launch path is broken, which matches the theory that the TUI entry point inside the Windows binary was replaced by a test script during packaging.

---

Environment

Item	Value
OS	Windows 11 25H2 (build 10.0.26200.8875)
Node.js	v24.18.0
npm	11.16.0
freebuff npm package	0.0.137
Binary target	win32-x64 (also tested win32-x64-baseline)

---

Likely root cause

The Windows release pipeline appears to be packaging an internal test entrypoint (test-bootstrap-caching.mjs, a bootstrap-caching test that expects PLUGIN_PATH present|missing arguments) into the shipped freebuff.exe. Since this is consistent across at least 8 versions/architectures of Windows builds, it is likely a systemic issue in the Windows release build config rather than a one-off bad upload.

---

Suggested fix

1. Verify the Windows release build is bundling the real CLI entrypoint, not test-bootstrap-caching.mjs or other test files.
2. Add a smoke test to the Windows release pipeline that runs the packaged binary with no arguments and asserts the TUI starts (or at least does not print a test-script usage message).
3. Re-publish the Windows binaries for affected versions (or at least latest).

---

Workaround for users (until fixed)

• Use Freebuff Desktop or Freebuff Web — full functionality, no CLI involved.
• Windows users can run the Linux build via WSL if available.

---

Reported with complete diagnostic evidence; happy to provide more detail or test new builds as soon as they ship.