@corenel/cli

The Corenel CLI — runs the host-agnostic agent harness in Node, in-process (no transport). Early/beta: the headless proof the kernel runs outside the browser.

npx @corenel/cli

Requires Node 18+. Bring your provider key via the environment.

Running corenel with no command opens an interactive agent in the current directory. On a terminal it opens the full terminal face; when output is piped, under TERM=dumb, in CI, or with --no-tui, it falls back to a plain line-by-line loop. --tui demands the full face and fails rather than falling back. --resume reopens the last conversation.

Assistant replies render as markdown. More verbs (run / ask / chat / login, and start --sidecar) are in progress.

Releasing

@corenel/term (the terminal face) is a real runtime dependency, not bundled into dist/cli.js -- see the note at the top of build.mjs. @corenel/term's own dist is bundled but keeps @corenel/harness and @corenel/protocol EXTERNAL (see packages/term/build.mjs) -- both the CLI and term import the harness directly, and they must resolve to the SAME installed copy, or the llm-execution feature guard and --debug logging silently apply to the wrong module instance. That makes all four packages real runtime dependencies of each other, and publish order matters:

pnpm --filter @corenel/protocol build && pnpm --filter @corenel/protocol publish
pnpm --filter @corenel/harness  build && pnpm --filter @corenel/harness  publish
pnpm --filter @corenel/term     build && pnpm --filter @corenel/term     publish
pnpm --filter @corenel/cli      build && pnpm --filter @corenel/cli      publish

Publishing any package against an unpublished dependency yields one that cannot install at all, so npx @corenel/cli fails before any verb runs.

Publish with pnpm, never npm: this CLI depends on @corenel/term as workspace:*, and pnpm rewrites the workspace: protocol to a real version at pack/publish time while npm ships it verbatim -- an npm publish from this workspace produces a manifest whose install fails with EUNSUPPORTEDPROTOCOL / Unsupported URL Type "workspace:", which is the very breakage this section exists to prevent.

All four versions must be bumped and published together, in the order above, every release -- even one that only touches a single package. pnpm rewrites every workspace:* dependency to the EXACT current version of that dependency at pack time. All four packages are pinned to the same harness version today, so a normal npm install of @corenel/cli resolves to one harness copy. Bump @corenel/harness and publish a new @corenel/term without also republishing @corenel/cli, and the tree that installs @corenel/cli gets the OLD harness version nested under it (frozen into the manifest @corenel/cli published against) plus the NEW harness version hoisted at the top level for @corenel/term -- two separate harness module instances again, silently. That is exactly the bug this section's ordering exists to prevent (see harnessSingleInstance.test.ts in this package's test/): registerGuard()/setAgentLogging() calls made through one instance configure a module the other never reads, so the llm-execution feature gate silently stops running and --debug logging can't be turned off. Every test in this repo stays green when that happens, because the in-repo workspace is symlinked (one instance by construction) and the build-output regression test only exercises that same symlinked layout -- neither one can see a real, version-skewed npm install.

Licensed under Elastic-2.0.