Unity Finally Connects the Terminal to the Editor

When working in Unity, the most awkward thing about an agent isn't that it can't write scripts.

It's that after writing them, it can't see what's happening inside the Editor.

Change one line of a Collider, then wait for compilation, wait for the domain reload, then enter Play Mode. Red shows up in the Console, you copy the log back, and it guesses another round. This loop is slow and fragile, and with every extra step you turn back into the middleman.

In mid-July, Unity released the Unity CLI. It's not yet another hidden Hub flag, but a standalone unity command. The docs still mark it experimental. But given today's division of labor — "AI writes the code, humans watch the Editor" — it at least targets the layer that is really stuck.

So I want to write down what it actually is, and, for someone like me who builds small projects with Unity on a Mac, where it's useful and where not to trust it just yet.

It's Actually Three Layers, Not a Slogan

Many people see "CLI" and assume it's just the Hub moved to the terminal. The official docs break it down fairly clearly:

The Unity CLI is a standalone binary for installing Editors, adding modules, opening projects and authenticating from the terminal; com.unity.pipeline lets it drive a running Editor (or a development Player); and unity command eval can run a piece of C# directly in an instance that's already up, without going through a full project recompile just to try one expression.

The first layer solves machine and environment problems: CI doesn't want to install the full Hub, scripts want JSON / TSV, and exit codes must be stable. The Hub's old -- --headless was slow and awkward; now it becomes:

PLAINTEXT

复制

curl -fsSL https://public-cdn.cloud.unity3d.com/hub/prod/cli/install.sh | UNITY_CLI_CHANNEL=beta bash
unity --help
unity install 6000.2.10f1 -m android ios webgl

Only the second layer is the Editor. Once the Pipeline package is installed in the project:

PLAINTEXT

复制

unity pipeline install
unity command
unity command <command-name>

Any static method with [CliCommand] added can become a command callable from the terminal. A project's own "import, run tests, enter Play, switch scenes" no longer has to be tied to menu clicks.

The third layer is eval. In the official demo, the agent is given "the player sometimes falls through the floor", uses unity command eval to inspect the live scene, finds the collider was disabled at runtime, turns it back on, and enters Play to verify. The point isn't whether the demo is flashy, but that the loop finally closes: observe, act, confirm — all happening inside the same living Editor.

This Is the Missing Piece for Agents

I've written quite a bit about Claude Code and Codex. They are already very strong inside a repository: editing files, running tests, reading diffs.

But a Unity project has one more layer: "engine state". The scene tree, Play Mode, importers, the AssetDatabase — these aren't in git and aren't in ordinary terminal output. In the past the community relied on all kinds of MCPs, screenshots and copying the Console. It worked, but wasn't stable and was hard to reproduce.

Unity's attitude this time is actually quite blunt: when you can run a shell, prefer unity command / eval; the CLI also ships with unity mcp, for agents that can't conveniently run a terminal directly. The old in-Editor assistant MCP is migrating toward this path. Both are free, and neither puts a subscription in your way anymore.

For me, what matters more isn't taking sides between brands but that the interface has the right shape.

Structured output, fixed exit codes, discoverable commands (unity command with no arguments lists what the current Editor exposes) — these are what an agent can call reliably. The "AI assistant" in the marketing copy can change; this execution layer had better not be changed again.

The official docs are also very clear: Unity's own in-Editor AI is just one consumer of this execution layer, not a replacement. Claude, Codex and local models can in theory all take the same road. This matters a lot for individual developers. I don't want to tie myself into one vendor's editor plugin ecosystem just to use an agent.

The Things I Actually Care About

1. It solves "seeing and verifying", not "making the game for you".

The agent will still make up APIs and mess up prefabs. The CLI just means it relies less on you as a human relay. Expecting it to build complete gameplay automatically is still early.

2. eval is fast, and also more dangerous.

It uses Roslyn, runs on the Editor's main thread, and can reach almost every API your project can reach. The official docs gate it with a security token and put it bluntly too: treat it as remote code execution. Local localhost, development builds, explicit authorization — these boundaries must be kept. A development Player can also attach the runtime component, but it's off by default and shouldn't go into production builds.

3. Pipeline needs Unity 6.0+, and the CLI itself is still experimental.

The docs' front page says experimental. The Hub now installs the CLI along the way, and you can also install it separately and unity upgrade it on its own. On Mac you can now also brew install --cask unity-cli. In other words: you can start using it in personal scripts and prototypes, but don't bet your entire release pipeline on it overnight.

4. Old Hub headless scripts need migrating.

If your repository still has "Unity Hub" -- --headless ... lying around, you have to change the commands following the official migration guide. This isn't a small rename; it's a switch to semantics that look more like a proper CLI.

What It Means for Indie Developers

When one person works on Unity, the biggest daily friction often isn't "can I install the Editor" but whether, after changing logic, you have to click Play by hand again and paste the error back into the chat window.

If the CLI + Pipeline stabilizes, here is where I'd want to use it first:

• Open a specific project and confirm the Editor version is right

• Run a batch of [CliCommand]s that I expose myself: enter Play, run a short automated check, output the result as JSON

• Let the agent use eval to ask questions about the live state, instead of asking me "what's in the Console"

Installing Editors and adding modules in CI is worth more to a company's pipeline. For a one-person small project, what's really valuable are the second and third: turning "a person clicking around in the Editor" into scriptable, reviewable steps.

It won't make a game for you. It will only make me spend less time being the agent's eyes and hands.

Final Thoughts

The Unity CLI isn't another "we fully embrace AI" slogan release. It's more like laying a foundation that should have been there long ago: the terminal can manage the environment, scripts can drive the Editor, and agents finally have a road that isn't so crooked to verify whether their changes are right.

It's still labeled experimental. I'll install it, try it, and collect the commands that reproduce reliably into my own little scripts. I won't bet builds, publishing and automated tests on it right away.

Whether a tool is good depends on whether it can tighten the feedback loop. This time, Unity has at least aimed at that loop.

https://unity.com/blog/meet-the-unity-cli

https://docs.unity.com/en-us/unity-cli/unity-cli