Repository navigation
@call-e/cli and @call-e/calle both install a 'calle' binary, and the plugin skills prescribe the bare command #109
Description
@call-e/cli and @call-e/calle both publish a binary called calle, and they are not the same program.
@call-e/cli bin: { "calle": "./bin/calle.js" }
@call-e/calle bin: { "calle": "./dist/cli.js" }
One drives the Developer API and has calls create, calls get, goals run, keyed off CALLE_API_KEY against api.heycall-e.com. The other is the MCP and brokered-login tool with auth login, call plan, call run, call recover, defaulting to a different host entirely. Different commands, different auth, different service.
Install both and npm links one of them without a word:
npm install @call-e/[email protected] @call-e/[email protected]
cat node_modules/.bin/calle | grep -o "@call-e/[a-z-]*/[a-z/.]*"
# @call-e/calle/dist/cli.jsThe SDK wins. No warning, no error, nothing in the install output.
That would be a footnote if the plugins did not prescribe the bare command. packages/claude-plugin/plugin/skills/calle/references/commands.md offers three forms, and the middle one is plain calle:
env CALLE_SOURCE=claude ... node packages/cli/bin/calle.js call run --plan-id <plan_id> --confirm-token <confirm_token>
env CALLE_SOURCE=claude ... calle call run --plan-id <plan_id> --confirm-token <confirm_token>
env CALLE_SOURCE=claude ... npx -y @call-e/cli call run --plan-id <plan_id> --confirm-token <confirm_token>In a project that has the SDK installed, the middle one runs the wrong program:
$ calle call run --plan-id p --confirm-token t
Unknown option: --plan-id
exit 1
An agent following the skill gets that back mid-workflow, with a plan already created and a confirm token in hand. The message does not hint that a different calle answered. The first and third forms are fine, so which of the three the agent happens to pick decides whether the call goes out.
Installing the SDK to write server code and the CLI to drive agent flows is a normal thing to want, and both are the shipped path for their own use case.
Suggested fix
Cheapest is to drop the bare calle form from the plugin references and keep the two unambiguous ones. npx -y @call-e/cli names the package, so it cannot be shadowed, and the explicit node packages/cli/bin/calle.js path is fine for a checkout.
The longer answer is one of the two binaries getting a different name. That is a breaking change, so it may not be worth it, but two published packages fighting over one command name will keep producing this.
Activity
Ray-56 commentedon Sep 5, 2026
Priority: P1 — executable-confusion and call-authorization risk. Confirmed from the registries:
@call-e/[email protected]and@call-e/[email protected]both export a binary namedcalle, from different repositories and with incompatible command/auth contracts. The productized skills passplan_idandconfirm_tokento the bare executable, so PATH ornode_modules/.binprecedence can send call-authorizing inputs to the wrong program. In an untrusted workspace, a shadowing executable is also a direct token-capture surface.Recommended remediation:
calleform from every agent skill/reference for commands carrying authentication or call-confirmation data. Use the verified repository-localnode packages/cli/bin/calle.jsonly inside this trusted checkout; otherwise use an invocation that explicitly selects@call-e/clirather than whichevercalleis first on PATH.auth login,call plan,call recover); do not fall through to an unknown executable after a mismatch.CALLE-AI/server-sdk-typescripton distinct long-term binary names (for example an API-specific name), with a deprecation/compatibility plan rather than silently changing one package.Release decision: removing ambiguous bare-command guidance is a backward-compatible safety correction and warrants patch releases for affected published plugin packages. Renaming or removing an existing published binary is breaking and requires a coordinated major-release maintainer decision across both repositories.
JJasonSun commentedon Sep 8, 2026
The agent invocation fix merged in #115. The five skills now use a bundled launcher that verifies a trusted
@call-e/clipackage, entry point, and MCP command help before forwarding JSON argument arrays without a shell. Mixed-install tests also verify that the SDK and a shadowingcalleexecutable receive no authentication or call-confirmation arguments.Correction to the original suggested workaround: with both packages installed, we reproduced
npx -y @call-e/cli, including the version-pinned form, selecting the SDK executable. Naming the package in an npx command is not sufficient to establish which implementation runs.The code is merged and Linux/Windows CI passed, but the npm updates are still pending in #96. As of September 8, npm
latestfor@call-e/cliremains0.5.0. The shared binary name itself remains tracked in server-sdk-typescript#20; the agent compatibility fix does not require that rename.JJasonSun commentedon Sep 10, 2026
The verified-launcher fix from #115 now ships in
@call-e/[email protected],@call-e/[email protected],@call-e/[email protected], and@call-e/[email protected]through release #96. The release workflow and Linux/Windows CI passed. I installed the published packages and verified that each plugin launcher selects and runs the published MCP CLI.The SDK CLI rename in server-sdk-typescript#20 / PR #21 remains deferred for internal discussion. This compatibility release does not require or include that rename.