How the CLI and app share state

The desktop app owns the active project, machine connection, and service state. Most CLI commands reach that state through the app's local HTTP API. The frontend itself uses Tauri IPC to call the shared service; it does not need the HTTP server enabled for normal desktop use.

Live commands

agent state, project open/save, design rendering, vector exports, and machine controls normally require the app's API server. Enable Local API in General settings and leave network access off when the CLI runs on the same computer.

These commands work on the app's current project. A script opening a different project changes what the desktop user sees.

Rendering

Design rendering is performed by the backend and does not need the canvas to be visible. It still requires the API server. Camera-overlay rendering asks the frontend to render the current overlay and therefore also needs the desktop UI to respond.

Direct local commands

Help, serial-port listing, and positional export gcode do not require the API server. Standalone G-code export loads the named project and locally saved machine profile through the shared checked generator. It cannot read the running machine's position. See G-code output.

Concurrent edits

Design transactions check the project snapshot before committing. If the project has changed, switched, or closed, the transaction fails instead of overwriting the newer state. Refresh the state and reconsider the requested edits before retrying.

Service-side project edits mark the project as changed so the desktop app can show unsaved work. Saving, recovery, and undo should not be treated as independent copies of the project.

UI state

The CLI does not expose every frontend interaction. Selecting tools, opening dialogs, and arranging panel docks remain desktop actions.