HELIX CLI

Scaffold, validate and publish HELIX worlds, items, devices and vehicles from the terminal. The same commands humans and AI agents use.

@hypersoniclabs/helix-cli is the front door for building on HELIX. It scaffolds world projects, resolves the systems a world pins, validates a bundle against the exact rules the server enforces, and publishes worlds (play-from-a-link browser games), Packages and Items.

npm install -g @hypersoniclabs/helix-cli
# or, always current: npx -y @hypersoniclabs/helix-cli@latest <command>

The binary is `helix`, the package is scoped

Install the scoped package, because a bare npx helix resolves to an unrelated package on npm. A global install goes stale. npx -y @hypersoniclabs/helix-cli@latest is always current; leave off @latest and npx reuses whatever copy is already installed globally. helix doctor tells you when anything in the toolchain is behind.

The complete command reference is generated

Command reference

Every command, subcommand, argument and option, generated from the CLI itself.

That reference is produced by loading the published CLI and walking the command tree it registers, so it cannot list a command that does not exist or miss one that does. The CLI's own help is the authority for the build you have installed:

helix --help
helix <command> --help

The main workflows

I want to	Start here
Build and publish a world	Quickstart: `helix init`, `helix install`, `helix validate`, `helix publish`
Publish a 3D item from a GLB	Publish an item from a GLB: `helix continuum publish-glb`, `helix continuum make-item`
Sell something in a world	Sell something for LIX: `helix product register`
Author a device or a vehicle	`helix device`, `helix vehicle`
Import from another engine	`helix bridge`
Check my setup	`helix doctor`, `helix whoami`

Account

helix login                       # opens the browser and stores a client token
helix login --no-browser          # print the sign-in URL instead
helix login --token <token>       # non-interactive, for CI
helix whoami
helix logout

Remote shell, container or CI? Do not wait for the browser login

The default login finishes through a callback on the machine that runs the CLI, so it cannot complete from an SSH-only host, a cloud runner or a container. Create a client token in Account → API keys, then sign that machine in explicitly:

helix login --token "$HELIX_CREATOR_TOKEN"

Keep the token in your secret manager, not in source control or shell history. The CLI validates it before writing ~/.helix/credentials.json. The MCP server reads the same file, so run this once before starting MCP on a headless host.

Source code is not uploaded by default

Every helix publish creates an immutable, playable build. It uploads your project source only when you ask for it:

helix publish dist --upload-source --source-dir .

Without --upload-source, HELIX keeps the built bundle that runs the world, not the editable project that produced it, and the CLI prints that outcome after every publish. Keep the project in version control and back it up: a published, optimised build cannot be turned back into your source.

For AI agents

Agents drive the same code paths through the MCP server, which registers one typed tool per workflow. Its tool reference is generated from the running server the same way.