Unity CLI – Manage and Automate Unity From the Terminal

Unity announced the Unity CLI on 20 July 2026: a standalone unity binary that manages editors, modules, projects and authentication from the terminal, plus an experimental package that lets you drive a running Editor from a script.

If you have ever fought the Unity Hub in a CI pipeline, this is the thing you wanted.

Three Layers, Not One Tool

It helps to see the release as three separate pieces, because they solve different problems:

Layer	What it does
The CLI	Manages Unity — installs editors and modules, opens projects, handles auth
`com.unity.pipeline`	Drives Unity — sends commands to a running Editor or dev Player
`unity command eval`	Reaches inside Unity — runs C# live in a running Editor, no recompile

Layer One: Managing Installs

The CLI ships as a single self-contained binary. There is nothing to install alongside it, and it adds itself to your PATH, so it is just unity from then on — and unity upgrade to update it in place.

Installing an editor with the modules you need is a one-liner:

unity install 6000.2.10f1 -m android ios webgl

The rest reads the way you would guess: unity editors lists what is installed, unity open launches a project with the right editor resolved, unity auth login signs you in, and unity modules list 6000.2.10f1 tells you which module IDs a version actually has.

At the time of writing, installation is via a shell script on the beta channel; Unity says support for brew, winget and apt is coming.

Why This Matters for Build Servers

Unity makes a point of it being a native binary, so it starts fast — the old Unity Hub headless path (-- --headless) took noticeably longer, and that gap compounds across the dozens of calls a build job makes.

The automation details are the giveaway that this was designed for CI rather than retrofitted to it:

Structured output with --format json or --format tsv, ready to pipe into your own tooling
Results on stdout, errors on stderr
A documented exit-code contract: 0 success, 1 error, 130 cancelled
Non-interactive installs with --accept-eula --yes
Service-account authentication from environment variables, so a headless agent needs no browser step
unity doctor for diagnosing environment, credential and configuration problems

That is a much better foundation than parsing log files and hoping, which is how most Unity build scripts have worked until now.

Layer Two: Driving a Running Editor

The second piece is com.unity.pipeline, an experimental package that lets a running Editor accept commands from the CLI, entirely over a local connection. It works with Unity 6.0 LTS and newer.

unity pipeline install    # add it to the current project
unity pipeline list       # which projects have it
unity command             # list commands a connected Editor exposes
unity command <name>      # run one

The commands are not a fixed set. Any static method in your project becomes one by tagging it:

using Unity.Pipeline.Commands;
using UnityEngine;

public static class MyPipelineCommands
{
    [CliCommand("greet", "Log a greeting and return its length")]
    public static int Greet(
        [CliArg("name", "Who to greet", Required = true)] string name)
    {
        Debug.Log($"Hello, {name}!");
        return name.Length;
    }
}

The package discovers it automatically — there is no registration step — and unity command greet --name World runs it against the connected Editor and hands back the result.

It also works against a running game. Drop the runtime component into a development build and unity command --runtime <player exec name> will pull live logs and query runtime status against a build that is already playing. It is localhost-only and off by default, and Unity is explicit that it is for dev and QA builds, never production.

Layer Three: `eval`, and the Agent Angle

The third piece is the one that raised eyebrows. unity command eval executes C# inside a running Editor or Player and returns the result, with no project-level recompile and no domain reload.

Unity’s own framing is that these features together “allow AI agents to operate Unity: observe a live project, act on it, and verify the result.” Their demo is a 25-second clip in which a developer hands an agent a plain-English bug report — “the player sometimes falls through the floor” — and the agent inspects the live scene through eval, finds a collider being disabled at runtime, re-enables it, and re-enters Play mode to confirm the fix.

Take the agent framing or leave it. The underlying capability is useful either way: a REPL against your live game is something Unity developers have wanted for a very long time, and plenty of debugging that currently means adding a Debug.Log, recompiling and replaying becomes a one-liner instead.

Should You Adopt It Yet?

A reasonable split:

The CLI itself — worth trying now if you maintain build automation. It is available today, and the worst case is that you keep your existing scripts.
The Pipeline package — it is labelled experimental and Unity says to expect it to evolve. Fine for internal tooling, risky as a load-bearing part of your release process.
eval in builds — treat it exactly as Unity does: development and QA builds only.

The wider point is that Unity is investing in the terminal as a first-class surface. For small teams, the constraint has rarely been “can Unity do this” — it has been “how many manual Editor steps stand between a commit and a build”. Anything that removes those is worth a look.

Best Unity Assets in 2026 for Unity 6 – the tools we actually keep installed
Why Is My Unity Build Slow? – build times, and what actually moves them
A Useful Countdown Timer Class in C# – a small, practical utility

Source: Meet the Unity CLI, Unity Technologies, 20 July 2026.