freebuff 0.0.95 on macOS arm64 starts TranscriptAPI/Exa CLI instead of Freebuff TUI

[Kenmege]

Summary

On macOS arm64, freebuff@0.0.95 installs successfully and freebuff --help / freebuff -v work, but running freebuff without args does not start the Freebuff TUI.

Instead, it prints what looks like an unrelated TranscriptAPI / Exa CLI help screen and exits.

I also see freebuff login fail immediately with:

error: too many arguments. Expected 0 arguments but got 1.

This looks like the interactive startup path is dispatching into the wrong program / wrong command handler.

Environment

• OS: macOS arm64 (Apple Silicon)
• Package: freebuff@0.0.95
• Install method: npm install -g freebuff
• Binary version: freebuff -v -> 0.0.95

What works

freebuff --help
freebuff -v

Both return expected Freebuff output.

What fails

1) Normal startup

freebuff

Actual output begins with:

tapi-auth.js v2.1.0 - TranscriptAPI Account Setup

  Creates a TranscriptAPI account and sets up an API key. No passwords
  are involved — the server sends a one-time verification code to your
  email, and once verified, the API key is saved automatically to your
  shell environment (~/.zshenv, ~/.bashrc) and agent config files so
  it's ready to use immediately.

…and then ends with:

Usage:
  node freebuff <search|contents|findsimilar|answer|research> [<json-string>]
  cat payload.json | node freebuff search
  node freebuff search --file ./payload.json

Env:
  EXA_API_KEY (env var) or .env file next to this script

This is not the Freebuff TUI.

2) Login subcommand

freebuff login

Actual:

error: too many arguments. Expected 0 arguments but got 1.

Expected: the documented login flow.

Reproduction

Fresh install / reinstall still reproduces:

npm uninstall -g freebuff
rm -rf ~/.config/manicode
npm install -g freebuff
freebuff

Also reproduces when:

• running in an empty directory
• invoking the downloaded binary directly from ~/.config/manicode/freebuff
• after completing auth and saving valid CLI credentials in ~/.config/manicode/credentials.json

Expected behavior

Running:

freebuff

should open the normal Freebuff TUI / login / waiting-room flow, not TranscriptAPI / Exa help text.

Running:

freebuff login

should start the login flow rather than erroring on the argument.

Notes

A few extra observations that may help narrow it down:

• The wrong output appears from the downloaded runtime binary, not just the npm wrapper.
• freebuff --help shows the expected Freebuff help text, so the binary is at least partially correct.
• The failure path looks consistent with the binary jumping into the wrong entrypoint only for interactive startup / login paths.

If helpful, I can test a patched binary or canary build.

[Kenmege]

Follow-up root cause found on my machine.

The breakage was not the Freebuff binary itself.

It was caused by the local agent loader recursively importing executable JS files from my home ~/.agents tree.

Specifically, these files were being picked up from a quarantine folder that lives inside ~/.agents:

• ~/.agents/skills-quarantine/2026-02-23/youtube-data/scripts/tapi-auth.js
• ~/.agents/skills-quarantine/2026-02-23/exa-search/exa-api.cjs

Those files are CLI entrypoints with side effects at import time (program.parse() / immediate main() execution), so when Freebuff loaded local agents, they executed and printed the TranscriptAPI / Exa help text instead of launching the TUI.

Once I moved the quarantine directory out of ~/.agents, normal freebuff startup worked again.

This suggests the underlying bug is in the SDK local agent loader scope, not just in Freebuff startup:

• sdk/src/agents/load-agents.ts skips skills/, but not other non-agent directories under ~/.agents
• it imports all *.ts, *.js, *.mjs, *.cjs files it finds
• that allows unrelated executable scripts to run during agent discovery

Likely fix ideas:

1. narrow agent discovery to explicit agent-definition filenames / conventions
2. skip known non-agent directories such as skills-*, scripts, lib, src, etc.
3. avoid importing arbitrary JS/TS files just to discover whether they are agents
4. require an explicit marker / manifest for loadable agents

Current local workaround that restored functionality:

• move ~/.agents/skills-quarantine outside ~/.agents

After doing that, both of these worked normally for me:

freebuff
freebuff --cwd /tmp/some-empty-dir

[MrSimonC]

Seeing a related but milder version of this on macOS 15 (Darwin 25.5.0), freebuff 0.0.95, fresh npm install -g freebuff under nvm Node v23.10.0.

Difference from the original report: I don't get the TranscriptAPI / Exa text at all. freebuff with no args just sits there silently - no output, no spinner, no prompt - until I Ctrl+C.

What works:

• freebuff --version -> 0.0.95
• freebuff --help -> prints (but exits via the terminal-reset sequences and effectively wipes the output - filing that as a separate issue)

What doesn't:

• freebuff (no args, fresh install, never logged in): hangs silently

Binary is fully present at ~/.config/manicode/freebuff (~86 MB). Wrapper index.js spawns it with stdio: 'inherit'. My guess: on a never-logged-in install, the binary blocks waiting for something without printing anything user-visible.

Minimal repro:

1. npm install -g freebuff
2. freebuff
3. Wait. Nothing happens.

[jahooma]

Thanks for diagnosing this! Working on a fix