CLI exits after ~6-10s in interactive TUI; bare `freebuff` prints "Usage: node mcp_proxy.js" (Crostini/Debian 12, 0.0.148+0.0.149)

[butchip25]

Summary

On ChromeOS Crostini (Debian 12, x86_64), the freebuff CLI has two reproducible problems:

1. freebuff with zero arguments prints Usage: node mcp_proxy.js <serverId_or_socketPath> and exits 1, instead of starting the CLI.
2. Any interactive TUI session exits by itself after ~6–10 seconds, with exit code 1, no error on screen, and nothing on stderr.

Non-TUI commands work perfectly: --version, --help, and login all behave correctly, and login waits indefinitely as expected. The fault appears confined to the interactive session path.

Both reproduce on 0.0.148 and 0.0.149 (0.0.149 is current latest on npm), so this is not a fresh regression.

Environment

• OS: Debian GNU/Linux 12 (bookworm) inside ChromeOS Crostini
• Kernel: 6.6.135-09383-g1140e4f27e24, x86_64
• Terminal: reproduced under a plain pipe, a script(1) PTY, and tmux 3.3a with TERM=xterm-256color
• Install: npm install -g freebuff (wrapper 0.0.149, binary linux-x64 0.0.149)
• Account: authenticated successfully (freebuff login completed; the previous 401s disappeared from the logs and ads render)

Issue 1 — zero-argument invocation

$ freebuff
Usage: node mcp_proxy.js <serverId_or_socketPath>
$ echo $?
1

Passing any argument avoids it:

Invocation	Result
freebuff	Usage: node mcp_proxy.js …, exit 1
freebuff --cwd .	TUI starts
freebuff --continue	TUI starts
freebuff --help / --version / login	correct

strace shows the freebuff process itself writes that line and exits — there is no node child and no mcp_proxy.js process spawned:

3341  write(2, "\33[0m\33[31mUsage: node mcp_proxy.js <serverId_or_socketPath>\33[0m\n", 63)
3341  exit_group(1)

The string serverId_or_socketPath does not appear in the freebuff binary (verified with strings across encodings, while other known CLI strings are found), which suggests an external module is being loaded and executed in-process.

Issue 2 — interactive session exits after ~6–10s

The TUI renders correctly (logo, project picker, and — inside a project — the normal UI with ads), responds to input (arrow keys/Enter navigate the picker), and then the process exits on its own after roughly 6–10 seconds.

The shutdown is deliberate and graceful, not a crash: it writes its own terminal-reset sequence, sleeps, unmaps its heap, then exit_group(1). No signal, no core dump, no stderr output.

31776 pwritev(1, [{iov_base="\33[?25h\33[0m\33]22;\7\33[>4;0m\33[?1003l…\33[?1049l…"}])
31776 clock_nanosleep(...)
31776 openat(AT_FDCWD, "/dev/tty", O_WRONLY) = -1 ENXIO
31776 exit_group(1)

Possibly relevant: an MCP socket connect immediately precedes shutdown

About 2 ms before the shutdown sequence begins, the freebuff process attempts a UNIX-socket connect that fails:

31776 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 18
31776 connect(18, {sa_family=AF_UNIX, sun_path="/tmp/datacloud-mcp---cwd.sock"}, 110) = -1 ENOENT
31776 close(18)
→ SIGWINCH/SIGQUIT/SIGABRT/SIGPIPE/SIGBUS reset to SIG_DFL
→ terminal reset → exit_group(1)

Note the socket name: datacloud-mcp- --cwd .sock. That third-party proxy builds its path as `/tmp/datacloud-mcp-${idOrPath}.sock` where idOrPath = process.argv[2]. Here it has picked up freebuff's own argv[2] (--cwd), which implies that proxy module is being loaded into the freebuff process and reading the host's argv.

That single mechanism would explain both issues: with no arguments argv[2] is undefined, so the module prints its usage banner and calls process.exit(1), killing the host process immediately.

The freebuff binary contains ~28 references to .agents and ~25 to mcpServers, so it appears to discover agent/MCP plugins from ~/.agents. This machine has Google's data-agent-kit-starter-pack installed there (and under ~/.gemini/extensions), which ships mcp/bin/mcp_proxy_bundle.cjs containing exactly the Usage: node mcp_proxy.js <serverId_or_socketPath> string.

Caveat, so this isn't over-claimed: removing that plugin's .mcp.json, and moving the entire plugin directory aside, did not stop the ~6–10s exit — so either freebuff finds an equivalent definition elsewhere, or the socket connect is a symptom rather than the trigger.

Ruled out

Each of these was tested and did not change the ~6–10s exit:

Variable	Values tested
Credentials	invalid token / no credentials file / freshly authenticated
Working directory	$HOME / inside a git repo / /tmp
Terminal	pipe / script PTY / tmux, TERM=xterm-256color
Version	0.0.148 and 0.0.149
CODEBUFF_NO_TERMINAL_WATCHDOG=1	no effect (confirmed "1" is an accepted value)
Launcher	npm wrapper vs. running the downloaded binary directly
Stale config	settings.json ({"mode":"MAX"}) removed
MCP plugin	plugin .mcp.json removed; entire plugin directory moved aside
Env	DATA_CLOUD_CURR_IDE_NAME unset
Verbosity	CODEBUFF_DEBUG=1, VERBOSE=1, CODEBUFF_TRACE=1 produced no additional output

The session log (~/.config/manicode/projects/*/chats/*/log.jsonl) for a failing authenticated run contains a single benign line (Enhanced CLI fingerprint generated successfully) — no error is recorded.

Additional note (security)

The CLI writes the account API key in plaintext into ~/.config/manicode/projects/*/chats/*/log.jsonl:

{"level":"ERROR","data":{"apiKey":"<redacted>","fields":["id","email"],"status":401}, ...}

Worth redacting, since these logs persist on disk and are easy to share when reporting bugs.

What would help

• Whether the interactive session path is expected to work when unrelated ~/.agents plugins are present
• A way to start the CLI with MCP/agent-plugin discovery disabled, to confirm or eliminate that path
• A visible error (or a log line) on this exit instead of a silent exit(1)

[butchip25]

Update: definitive root cause found — both issues have a single mechanism, now confirmed

Follow-up with new strace evidence. The caveat in my original report ("moving the plugin aside did not stop the exit") is resolved: that test was invalid, and with a corrected test both issues disappear completely.

The flaw in the earlier "ruled out" test

freebuff scans all of ~/.agents recursively — not just ~/.agents/plugins/. My earlier test renamed the plugin directory but left it inside ~/.agents, and strace shows freebuff discovering and loading it at the renamed path anyway:

openat(AT_FDCWD, "/home/butchi/.agents/data-agent-kit-starter-pack.disabled-for-freebuff-test/mcp/bin/mcp_proxy_bundle.cjs", O_RDONLY) = 14

So the "plugin moved aside, exit persisted" line in the original report should be disregarded.

Confirmed mechanism

freebuff opens and executes at least mcp/bin/mcp_proxy_bundle.cjs in-process (it also reads mcp/build.js, mcp/dist/index.js, mcp/server.ts, and mcp/tools/*.ts, though for those I can only attest scanning, not execution). Running in the host process, the proxy's idOrPath = process.argv[2] picks up freebuff's own argv:

• Zero args → argv[2] is undefined → it prints Usage: node mcp_proxy.js <serverId_or_socketPath> and process.exit(1) — issue 1, instant.
• --cwd . → argv[2] is --cwd → it treats that as a server id and tries /tmp/datacloud-mcp---cwd.sock. Timestamped strace of the main pid shows three connect attempts at ~1s intervals, then exit_group(1) 65 ms after the third failure:

14:04:42.043963 connect(20, {sun_path="/tmp/datacloud-mcp---cwd.sock"}) = -1 ENOENT
14:04:43.050963 connect(22, {sun_path="/tmp/datacloud-mcp---cwd.sock"}) = -1 ENOENT
14:04:44.061894 connect(22, {sun_path="/tmp/datacloud-mcp---cwd.sock"}) = -1 ENOENT
14:04:44.126159 write(22, "\33[?1049l…")        ← terminal reset
14:04:44.128437 exit_group(1)

That retry-then-give-up loop, on top of ~4-5s of TUI startup, is exactly the reported "exits after ~6–10s" — issue 2.

A/B confirmation

With ~/.agents/plugins/data-agent-kit-starter-pack moved fully outside ~/.agents:

Test	Before	After
bare binary, zero args	usage banner, exit 1 instantly	TUI starts, survives
interactive TUI from $HOME	self-exit ~8–10s, code 1	ran 47s until my harness timeout
interactive TUI in a project dir	self-exit ~8–10s, code 1	ran 30s+ until harness timeout

Same harness (script(1) PTY) in all runs; no other variable changed. Both issues gone.

Workaround for anyone else hitting this

Move any third-party plugin containing runnable JS out of ~/.agents entirely (renaming inside ~/.agents is not enough). On this machine, Google's data-agent-kit-starter-pack installs a copy there; Gemini CLI and Claude Code keep their own copies elsewhere (~/.gemini/extensions, ~/.claude/plugins/cache), so the ~/.agents copy was redundant. Note the plugin's installer will recreate it there if re-run.

For the maintainers

The core bug: agent/plugin discovery under ~/.agents executes discovered module code inside the freebuff process, where any script that inspects process.argv or calls process.exit() misbehaves or kills the CLI. Suggested fixes, in increasing strength: pass the configured args instead of leaking host argv; run discovered MCP servers in a child process as configured (command/args) rather than in-process; or gate in-process loading on an allowlist/manifest instead of executing whatever .cjs/.js is found in the tree.

[lifelmy]

I can work on this. I reproduced the unsafe discovery path in source: the SDK recursively treats every .js/.cjs/.mjs/.ts file under .agents as an agent module and imports it before checking for an agent definition, so unrelated plugin executables can observe the host argv or terminate the CLI. I will first add a regression fixture proving non-agent files under a nested MCP/plugin directory are not executed, then keep the discovery filter minimal and run the focused SDK tests plus the repository-required checks. I will open only a linked draft PR if the validation passes.