CLI & local development

The browser editor covers the whole loop, but at some point you want your own editor, your own git and your own tooling. The lecodes CLI brings the project to your machine: local development with full IntelliSense, hot reload straight to your phone over the local network, headless checks without a device, and one-command sync with the platform.

The CLI is the npm package lecodes-cli (Node ≥ 18); the command it installs is called lecodes:

npm i -g lecodes-cli        # then: lecodes <command>
npx lecodes-cli <command>   # or without installing

No Node on the machine? Grab the standalone build from the Downloads page: unpack the archive and run ./lecodes install — the bundle is copied to a library folder and lecodes lands on your PATH.

Some commands live in separate packages the CLI installs on first use into ~/.lecodes/peers after a prompt (--yes or LECODES_YES=1 skips it): lecodes-renderer for render and test, lecodes-design for design, lecodes-3d-editor for scene and thumbs, lecodes-assets for assets. The standalone build resolves no npm packages, so those commands need the npm install.

You can start without the platform at all: init scaffolds a project right on disk — no login, no server.

lecodes init myapp
cd myapp
lecodes dev

init writes a starter main.ts, the SDK types, a tsconfig.json, a CLAUDE.md for AI agents and a first flow test under tests/ — VS Code autocompletes every global immediately, offline. The command is idempotent: existing files are never touched. The rules from Anatomy of a project apply here too — no package imports, an entry point with no exports.

The heart of local development. lecodes dev starts a dev server on your local network and prints a QR code — scan it with the le.codes app and the project opens on your phone, natively. From there the loop closes itself:

• Every save recompiles and hot-swaps the running app in place on the device; a build error rolls back to the last good version.
• The device's console.log and errors stream back to the terminal.
• The URL is stable across runs — the phone reconnects to the same address.

No login needed; assets are served from the working tree. Flags: --port (default 4499), --host if the LAN address was auto-detected wrong, --entry, --no-qr.

The same project, with the same hot reload, opens on the other hosts too — all of them at once if you like:

lecodes dev --web          # in the browser (the light web host; camera and map have web twins)
lecodes dev --desktop      # in a native window on Windows or Linux; --fps draws the frame counter
lecodes dev --android      # on a phone over USB via adb reverse — no Wi-Fi, no LAN address

--android also does a bounded check: lecodes dev --android --time 12 --png phone.png launches the app, screenshots the device after 12 seconds, force-stops it and exits 1 on a crash — handy in CI.

The second scenario: the project lives on le.codes and you work on a local copy.

lecodes login                       # opens the browser to authorize this machine
lecodes clone <uuid-or-url> myapp   # files + resources + types
cd myapp
# …edit in your own editor…
lecodes status                      # what changed
lecodes diff                        # line-by-line diff vs the server
lecodes push -m "Tweak the menu"    # all edits as one checkpoint

The model is simpler than git — no staging, no branches. push sends your whole working tree and the server atomically rebuilds it into one checkpoint: adds, edits, deletes and moves at once; renames keep their history, unchanged binaries are never re-uploaded. pull takes the project's current server state (pass paths to update only those; --force discards local edits). If the server has moved on, push stops and shows what would be overwritten.

A local project joins the platform whenever you decide:

lecodes link                         # create a server project for this folder
lecodes link --push -m "v1"          # …and push the first checkpoint right away
lecodes link --project <uuid>        # adopt an existing project — shows what push would change first

Metadata lives in .lecodes/ — it's like .git: commit it or don't. Types are fetched from the server on clone, pull and link, so they always match the deployed runtime. lecodes create <name> makes a new project on the server, and push --publish deploys the project live along with the checkpoint.

lecodes compile -o app.js         # the whole project as one portable bundle
lecodes render --png shot.png     # a screenshot of the app, no device needed
lecodes render --script demo.json # a scenario: taps, typing, frames — then the snapshot

compile builds the very bundle from Anatomy of a project — locally, in under a second. Without -o the bundle goes to stdout (pipeable), --no-minify keeps it readable. For a local init project the bundle is self-contained — you can open it in le.codes Desktop.

render runs the project headless and returns a semantic JSON snapshot of the interface — or a PNG with --png. That's the foundation for automated checks and AI assistants: an agent edits the code, renders, and sees the result itself. UI and 2D render; a 3D scene comes back as JSON with no pixels — for pixels, lecodes render --desktop drives the native host (Windows and Linux).

lecodes test                 # every tests/*.flow.json plus the flows derived from the design
lecodes test hero --logs     # one scenario, with the app's console.log forwarded
lecodes test --json          # a machine-readable report — for CI

A scenario is a JSON list of steps — tap, type, scroll, wait, frames, drag, keys — and expect checks against the semantic snapshot or the game log (expect.log). Time is deterministic: setLoop, 2D physics, animation and aspects advance in fixed 1/60 steps driven by the scenario, never by a wall clock, so a flow that passes once passes every time. 3D physics in headless is real — the same Jolt as on the device. A failing step dumps the frame as JSON and PNG under tests/.artifacts/<flow>/.

When the project has a design board, test derives flows from its screen-to-screen transitions and checks the built app against the designed navigation; backend responses for those come from tests/fixtures.json.

An app can be shared by QR link without a single native build. When you need your own binary — for a store or for the desktop — lecodes app prepares it:

lecodes app init ios --team ABCDE12345    # an Xcode project in ./ios with your bundle id
lecodes app init android                  # a Gradle project in ./android
lecodes app sync                          # pull the icon, versions and plugins from app.json
lecodes app build ios                     # build; app upload ios — to App Store Connect
lecodes app build desktop                 # a portable folder for Windows, Linux and macOS

The shell runs the compiled bundle offline and is never pushed to the platform. The native SDK version is pinned in app.json so builds stay reproducible; lecodes app update moves the pin. Xcode and Android Studio are needed for the build — there is no cloud build yet. Push notifications are testable without keys: lecodes pn send "Hello" sends one to the registered devices under your login.

For games and 3D, the same command carries the content pipeline:

• lecodes assets convert model.fbx — FBX to GLB with textures embedded; probe shows what's inside a model, doctor fixes the usual problems (bone cap, KTX2, scale), retarget moves animations from a different skeleton — Mixamo included.
• lecodes shaders — your own .mat materials: list, compile, update after an engine upgrade.
• lecodes lightmap — bake the level's static lighting, read the numbers and the bake's layers.
• lecodes navmesh — build the level's navigation mesh.

What the engine itself can do is on the Engine page.

The same command hosts two more local tools:

• le.codes Design (lecodes design) — a live canvas of screens for designing an app together with an AI assistant.
• The scene editor (lecodes scene) — a visual editor for .scene.ts files: a scene tree, an inspector and a gizmo; edits are written straight back to the source, and external IDE edits hot-reload.

Both register MCP servers, so an AI agent in the terminal renders the board's screens and reads the scene state directly. And lecodes update moves everything the project depends on to its newest state, in dependency order: the desktop host, the shader compiler, the shaders themselves, the types, the shell pins and the optional packages.