@call-e/cli and @call-e/calle both install a 'calle' binary, and the plugin skills prescribe the bare command

[cnpierrepapi]

@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/calle@0.7.0 @call-e/cli@0.5.0
cat node_modules/.bin/calle | grep -o "@call-e/[a-z-]*/[a-z/.]*"
# @call-e/calle/dist/cli.js

The 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.

[Ray-56]

Priority: P1 — executable-confusion and call-authorization risk. Confirmed from the registries: @call-e/cli@0.5.0 and @call-e/calle@0.7.0 both export a binary named calle, from different repositories and with incompatible command/auth contracts. The productized skills pass plan_id and confirm_token to the bare executable, so PATH or node_modules/.bin precedence 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:

1. Immediately remove the bare calle form from every agent skill/reference for commands carrying authentication or call-confirmation data. Use the verified repository-local node packages/cli/bin/calle.js only inside this trusted checkout; otherwise use an invocation that explicitly selects @call-e/cli rather than whichever calle is first on PATH.
2. Make command selection fail closed. Before passing secrets, verify the resolved implementation/package and that it exposes the MCP CLI contract (auth login, call plan, call recover); do not fall through to an unknown executable after a mismatch.
3. Add tests with both packages installed, plus a fake earlier PATH shim, and assert that no token/confirmation argument reaches the conflicting binary.
4. Coordinate with CALLE-AI/server-sdk-typescript on 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.