uigenx

Author Unity 6 UI Toolkit interfaces as plain files in git, then compile them into UXML, USS and C#.

ugx is the command line half of UI Creator. The project it edits is a folder of JSON documents and native .uss, so it diffs and merges like the rest of your code. Exporting is deterministic: the same project produces the same bytes, every time.

pnpm dlx uigenx init ./ui --unity ../MyGame
pnpm dlx uigenx export --to unity

Install

pnpm add -g uigenx        # npm install -g uigenx
pnpm dlx uigenx --help    # without installing

Node 24 or newer. sharp and the Claude Agent SDK are optional dependencies: without them everything works except sprite generation and agent runs, and both say so when you reach for them.

Getting started

ugx init ./ui --unity ../MyGame   # scaffold a project, detect the Unity folder next door
ugx screen list                   # what is in it
ugx export --to unity             # write UXML, USS, C# and .meta into Assets/UI
ugx studio                        # open the visual editor

No Unity project at hand, or you would rather move the files yourself:

ugx export --zip ./ui-export.zip  # unzip it over Assets/UI whenever you like

Commands

| Command | What it does | | -------------------------------------- | ---------------------------------------------------------------------------------------------- | | ugx init [dir] | Create a project. Finds a Unity project nearby and wires the export root to it. | | ugx screen list\|add\|rm | Screens in the project. | | ugx node get\|add\|set\|rm | Elements inside a screen or component, addressed by id or selector. | | ugx token list\|set | Design tokens, compiled into a :root stylesheet. | | ugx import <path> | Bring existing Unity UXML and USS into the project. | | ugx export | Compile. --to unity, --to dir --dir <path> or --zip <path>. --dry-run prints the plan. | | ugx review | Layout, token, binding and accessibility checks. | | ugx studio | Serve the visual editor, fetching @uigenx/studio the first time. | | ugx daemon start\|stop\|status\|logs | The local process that owns the project and talks to Unity. | | ugx unity status\|emit | Talk to a connected Unity editor. | | ugx doctor | Check Node, the project, the daemon and the Unity install. --fix repairs what it can. |

Every command takes --json and then prints exactly one JSON document on stdout, with all messages on stderr, so it scripts cleanly.

The studio

The visual editor is a separate package, so a CI machine that only runs ugx export never downloads a web app. The first ugx studio fetches it:

ugx studio                       # brings a daemon up with it
ugx studio --background          # detached, hands the shell back
ugx studio --stop                # stop the one running in the background
ugx --no-daemon studio           # studio only, browser held projects
ugx studio --no-install          # fail instead, for a locked down environment

A daemon starts alongside the studio, because without one no project on disk is reachable from the browser. --no-daemon skips it, which leaves the folder and browser modes. Stopping the studio stops that daemon too, but never one that was already running when the studio started.

See @uigenx/studio.

The daemon

Most commands work without it. Start it when you want file watching, a live Unity connection or several clients on one project:

ugx daemon start
ugx unity status

It also starts with no project at all, which is how a fresh machine gets going: bring the daemon up, open the studio, and create the first project from the start screen. The daemon writes exactly what ugx init would have written.

pnpm dlx uigenx daemon start   # anywhere, no uigenx.project.json needed
pnpm dlx uigenx studio

It listens on 127.0.0.1:4821 and writes a token to .uigenx/daemon.json with mode 0600. Nothing is exposed off the loopback interface. --no-daemon on any command opens the project directly instead and takes the store lock for the duration.

Unity side

Nothing to install. The export carries the UI Creator runtime into Uigenx/ beside the screens, so a Unity project opens on any machine with nothing but the files in its own repository.

The exporter writes Generated/ and Uigenx/ on every run, and the .asmdef and Scripts/ exactly once, so the C# half you fill in and the references you add are never overwritten. Upgrading the CLI and exporting again is what upgrades the runtime, which is why the two can never disagree about the code they share.

A project that still declares com.uigenx.runtime in Packages/manifest.json should drop that entry: two copies are two assemblies with the same name, and Unity compiles neither. ugx doctor says so if it happens.

Configuration

| Variable | Meaning | | ------------------- | ------------------------------------------------------------------------ | | ANTHROPIC_API_KEY | Agent runs. Also read from ~/.uigenx/config.json as anthropicApiKey. | | OPENAI_API_KEY | Sprite generation. Also openaiApiKey in the same file. | | UGX_DAEMON_PORT | Port the daemon listens on, default 4821. |

Keys are never written into a project folder and never logged. ugx doctor reports whether it can see them without printing them. The studio can set them too, under the gear at the foot of the left rail, which writes the same ~/.uigenx/config.json; an environment variable always wins over the file, and the studio says so when one does.

License

MIT