The Unity CLI: What Ships Today, What Is Still Broken, and Why It Matters More Than Unity AI

On July 20, 2026, Unity released a standalone unity binary, an experimental com.unity.pipeline package, and the ability to execute arbitrary C# inside a running Editor from a terminal. Etienne Whittom, VP of Authoring Platform, summarized the design in one line: the CLI manages Unity, the Pipeline package drives it, and eval reaches inside it.

In May we wrote about the Unity AI open beta and reported what the developers actually testing it were saying in Unity's own discussion thread. The consensus then was that Unity was fighting the wrong battle: stop competing with frontier models head-on, and build the surface that lets external agents drive the Editor. Two months later, that is what Unity shipped. This release matters more than Unity AI did, and the reception in the same community reflects it. It is the first time external tooling has had a supported way into the Editor, which makes a whole class of studio automation practical to build and, more to the point, practical to keep running.

Updated November 11, 2026. The CLI is at 1.0.0-beta.17, Unity has deprecated its in-Editor MCP server in favor of the CLI, and several details changed since July. The next two sections are new. The rest is the July 22 post, with a dated note wherever a fact moved.

Unity CLI vs Unity MCP

The MCP server that shipped inside the AI assistant package (com.unity.ai.assistant) with the Unity AI beta in May is deprecated. Its own documentation now opens with "Unity MCP server is deprecated. Use the Unity command-line interface (CLI) instead."

unity mcp is a separate thing and it is staying. It is a mode of the CLI, built into the same unity binary, that starts an MCP server over stdio and exposes the commands of a connected Editor as tools. Unity's migration page says it "replaces the in-Editor server" and "remains fully supported". Community servers such as CoplayDev's unity-mcp (about 15,900 GitHub stars in November 2026) and IvanMurzak's Unity-MCP (about 4,600) are not affected by the deprecation.

For an agent, Unity's advice is to skip MCP when it can. The same migration page says the unity command and unity eval commands "drive the Editor directly, without MCP in between. They're faster and use fewer tokens than MCP. Use these commands if your agent can run shell commands." MCP mode exists for the other cases, which Unity describes as agents and harnesses that "can't run arbitrary shell commands" and models that "don't compose command lines reliably". The unity-cli skill Unity publishes for coding agents says it in one line: "MCP is for clients that have no shell." Since 1.0.0-beta.16 (November 3), unity setup all no longer registers the MCP server for coding agents that can run shell commands.

A coding agent with a terminal, such as Claude Code, Codex or Cursor's agent, should call the CLI directly with Unity's skill installed. A chat client with no shell, such as Claude Desktop, needs unity mcp, and unity mcp configure <client> writes the configuration for 16 clients. If you are still on the in-Editor server, the same command finds the old entry and offers to replace it.

This changes how to read our own recommendation further down. In July we called the pattern a tailored MCP layer. The tailoring is the part that pays: a small set of project-specific commands that return terse, structured results. Those commands are registered once in C# and are reachable both ways, as unity command <group> <name> from a shell and as tools through unity mcp, so the transport is now something you choose per client.

What Changed Since July

The current install commands:

# macOS or Linux
curl -fsSL https://unity.com/install.sh | bash
brew install --cask unity-cli
 
# Windows
winget install Unity.CLI

What Actually Shipped

The CLI is a single self-contained binary with no dependencies. Installation puts it on your PATH, and unity upgrade updates it in place. It covers Editor installs (unity install 6000.2.10f1 -m android ios webgl), module discovery (unity modules list), project launching (unity open), authentication (unity auth login), licensing including floating and offline activation workflows, Unity Cloud organizations and projects, project cloning from GitHub, GitLab and Unity Version Control, and unity doctor for diagnosing environment and credential problems. A fresh machine needs nothing else, not even the Unity Hub desktop app.

In July, installation ran through the beta channel:

# macOS or Linux
curl -fsSL https://public-cdn.cloud.unity3d.com/hub/prod/cli/install.sh | UNITY_CLI_CHANNEL=beta bash
 
# Windows
$env:UNITY_CLI_CHANNEL='beta'; irm https://public-cdn.cloud.unity3d.com/hub/prod/cli/install.ps1 | iex

Support for brew, winget and apt is planned but not shipped. The Unity engineer maintaining the CLI said publicly that distributing prebuilt binaries through GitHub Releases is waiting on internal approvals, and pointed developers at the raw CDN bucket in the meantime. (November 2026: brew, winget, apt and rpm have all shipped. The current commands are in the section above.)

Because it is a native binary rather than the old Unity Hub headless path, it starts fast. That difference is easy to dismiss until you count the calls: a CI job or an agent session makes dozens of them, and startup cost compounds across every one.

The second layer is com.unity.pipeline, added to a project with unity pipeline install. It lets a running Editor accept commands from the CLI over a local API, on Unity 6.0 LTS and newer. The commands are not a fixed set. Any static method in your project becomes one by adding a [CliCommand] attribute, with [CliArg] on its parameters, and the package discovers it automatically:

[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;
}

Running unity command with no arguments asks a connected Editor to report the operations it exposes. The same runtime component can be dropped into a development build, so unity command --runtime <player exec name> reaches a running game to pull live logs, query runtime state, or hot-reload code. It is localhost-only and off by default, intended for dev and QA builds and never production.

The third layer is eval. unity eval "return UnityEditor.EditorApplication.isPlaying;" evaluates a C# expression inside a running Editor and returns the result. It is compiled with Roslyn and executed on the Editor's main thread, so it reaches any engine or editor API the project can reach, and it is gated behind a security token. There is an eval_file variant for longer scripts and a --runtime flag that aims the same capability at a live Player. Nothing gets recompiled, and no domain reload happens. The usual edit, recompile, relaunch cycle costs seconds at best. Eval answers in milliseconds against an instance that is already running.

One small tell about how fast this surface is moving: Unity's announcement post writes the command as unity command eval, while the release notes and Unity's own engineers in the forum thread use unity eval. Check unity --help on the version you install rather than trusting either. (November 2026: the Pipeline documentation lists it as script eval, and eval_file is gone.)

The Loop Unity AI Could Not Close

When we tested Unity AI in May and asked it directly whether it could test a game, it answered candidly that it cannot play the game, cannot see the Game View during Play Mode, and cannot simulate user input. It could check whether objects exist and whether properties changed, take Scene View snapshots, and read the Console. That is static validation, not a QA loop.

The Pipeline package plus eval is the missing half. An agent can now open the project, apply a change, run the tests, enter Play Mode, query the live scene graph for what actually happened, read the result, and decide what to do next, without a human copying console output back and forth. Unity's own demo makes the point with a bug report written in plain English, "the player sometimes falls through the floor," where the agent inspects the live scene, finds a collider disabled at runtime, re-enables it, and re-enters Play Mode to confirm the fix.

Two properties do the work here. The CLI emits structured JSON, TSV and NDJSON with a predictable exit code contract (0 success, 1 error, 130 cancelled, and 6 when tests execute but fail, which became 8 in August), so a model gets parseable results instead of scraped console text. And the Pipeline package makes the Editor self-describing, so an agent discovers what it can call at runtime instead of working from a hardcoded list. Any project-specific operation your team registers with an attribute becomes a tool the agent can invoke.

Unity is explicit about where this sits relative to its assistant products. In their words, Unity AI is the part that reasons about your project and decides what to do, while the CLI and Pipeline package are the execution surface that carries those decisions out, and "Unity's AI is one consumer of it, not a replacement for it." That is a more honest framing than anything in the Unity AI launch, and it is the correct one.

Worth noting for anyone who read our May piece: the CLI ships its own MCP mode. The previously existing Unity MCP is not required, unity mcp includes setup commands, and Unity's engineers describe the new implementation as better on performance, focus handling, domain reloads, and talking to multiple Editors at once. They also confirmed in the thread that the MCP is now free with unlimited concurrent connections on the latest version.

The CI Story Nobody Is Covering

Most of the coverage has focused on agents. For most teams the build automation half of this release is the more immediately useful one, and it has nothing to do with AI.

unity test runs Edit Mode and Play Mode tests through the Editor test runner in batch mode, writes NUnit XML through --output, and returns exit code 6 when tests run and fail (8 since 1.0.0-beta.6), which is exactly the distinction a pipeline needs between "the job broke" and "the tests found something." unity build handles Android signing with keystore and key configuration, symbol generation and target SDK, and exports APK, Android App Bundle or an Android Studio project. Build versions can be derived from Git tags and repository history through --versioning-strategy, and a modified working tree blocks the build unless you pass --allow-dirty-build. Headless agents authenticate with a service account through environment variables, floating license servers are supported, and there is real proxy support including authenticated proxies with Kerberos and SPNEGO.

Anyone who has maintained a homegrown Unity CI rig built on -batchmode -quit -executeMethod and a pile of parsing hacks knows how much of that stack this replaces. One developer in the thread put it well: a lot of Jenkins users are raising a beer.

Where It Breaks Today

This is a beta shipped through a beta channel, and the Pipeline package is marked experimental. Unity says so plainly in the documentation. Treat it accordingly.

The most consequential bug reported in the first days hit precisely the workflow the release is meant to enable. Entering Play Mode triggers a domain reload, which regenerates the Pipeline server's bearer token and rewrites Library/Pipeline/.unity-pipeline-port. An MCP client that read the token at process start keeps using the stale one, so every subsequent tool call fails with 401 Unauthorized, permanently, for the life of that client process. Leaving Play Mode does not recover it. The only fix is restarting the MCP client, which in an agent session means losing the connection to the Editor mid-task. Unity replied that a fix landed and ships this week. It shipped on July 23.

The Editor itself is still not fully agent-compatible, which the Pipeline package mitigates rather than solves. Developers report the Editor sometimes requiring foreground focus before it actually refreshes assets or reloads the domain, so an agent believes it recompiled when it did not, and modal dialogs (the unsaved scene prompt, for one) block an agent that has no way to click them. Unity's current answer is to launch the Editor with -automated, which takes the default action on every dialog while the Editor is open and should only be used for Pipeline-connected sessions. A real fix needs an Editor change and backports.

Performance is honest but not yet competitive with hand-built tooling. A studio developer benchmarked the official CLI against their own internal Unity tooling and reported per-call process latency of roughly 0.80 seconds versus roughly 0.05 seconds, about sixteen times slower, along with poor token efficiency on basic tasks and missing operations such as reordering objects in the hierarchy. Their approach was composable shell tools in the Unix tradition, which compounds well across multi-step work. Unity's response was to benchmark that project and adopt it as the baseline for optimization work, which is the right answer, but the gap exists today.

There is also a discoverability problem that is inherent to the format. An MCP server hands an agent a tool list with descriptions. A CLI hands an agent nothing, so the model reinvents usage from scratch unless you teach it. Unity's answer is a unity-cli skill in their public skills repository, installable with npx skills add Unity-Technologies/skills. It works, and it is the right pattern, but it means the CLI is not self-sufficient as an agent surface. You are shipping a skill or an AGENTS.md alongside it. Profiler and frame debugger integrations are planned before general availability and are not in yet. (November 2026: the Profiler commands have arrived.)

The Reception Tells You Something

The Unity AI beta drew hostile trade press and a developer thread full of people telling Unity it was building the wrong thing. The CLI thread reads completely differently. A developer who opened by describing himself as consistently critical of Unity for the last four years called the CLI awesome and thanked the team, with particular appreciation that it works without any AI integration at all. Another had spent the past year using AI with Godot specifically because Unity did not support this workflow. A developer who had written strongly worded feedback about the MCP limitations opened his reply by applauding Unity for listening.

The difference is that this release gives developers a primitive instead of a product. Unity built the execution surface and left the choice of agent, or of no agent at all, to the developer. That is the correct division of labor, and it is what the community asked for in May.

Our Take: Build a Tailored MCP on Top of It

Read past the rough edges and this is a real unlock. The hard part of driving Unity from an agent was never the reasoning. It was the integration: an editor-side bridge you owned yourself, that broke on domain reload, that wanted the Editor in the foreground, and that could not tell you what happened once the game was actually running. That substrate is now first-party and supported, and the applications that were previously too fragile to maintain become worth building. Automated QA that enters Play Mode and verifies behavior rather than checking that objects exist. Live-ops content variants generated, built, and validated without a person in the loop for the mechanical steps. Economy and balance tuning swept across many runs, which Unity's own engineers call one of the strongest uses of the CLI. Runtime introspection of a development build while it plays. Several Editor instances driven at once, which turns agent work that used to serialize into work that fans out.

What we keep finding most effective for studios, though, is not pointing an agent at the general-purpose tool surface. It is building a tailored MCP server on top of the engine integration, optimized for three things that turn out to be the same problem: performance, output quality, and token cost. A generic surface makes the model discover its way through a task across many small calls, each returning verbose payloads it has to read and reason over. A tailored surface exposes the operations your pipeline actually performs, returns terse structured results, and collapses what would be a fifteen-call exploration into one call with a predictable shape. Fewer tokens per task, faster wall clock, and fewer wrong turns, because there are fewer opportunities to take one.

That is not only our finding. It is the most useful data point in Unity's own announcement thread, where a studio developer measured their internally built tooling at roughly sixteen times lower per-call latency than the official CLI and described its token efficiency on basic tasks as poor, having deliberately built around small composable commands. Unity took the criticism well and adopted the project as an optimization baseline. Both things are true at once: the official surface is the right foundation, and a tailored layer on top of it beats using it raw.

What this release changes is the cost of building that layer. Previously it meant owning the entire bridge into the Editor, which is why community MCP servers were a maintenance liability. Now [CliCommand] turns a project-specific operation into a C# method with an attribute, discovered automatically and reported to any agent that asks a connected Editor what it exposes. Eval covers everything not yet registered, which makes the development loop for the tooling itself fast: prototype an operation as an eval expression against a live Editor, and once it proves useful, promote it to a registered command for the latency and token savings. The work moves off integration plumbing and onto the part that actually pays, which is choosing the right operations and shaping what they return. That is the same architecture we described in our autonomous pipeline that takes a one-paragraph brief to a tested feature in a live Unity game, with a much better foundation underneath the engine-facing half of it.

For studios, the practical read is this. If you run Unity in CI, evaluate the build and test commands now, because that half is useful today independent of anything AI-related. If you are running agents against Unity through a community MCP server, plan a migration but do not rush it, because the beta is moving fast enough that command names are still shifting under you and the Play Mode token bug was only just fixed. If you are starting now, learn eval first, then decide which of your recurring operations deserve to become registered commands. That promotion step is where most of the performance and token savings live.

The thing to avoid is reading this as the finished answer. Unity has shipped good primitives on a beta channel, and primitives are not a pipeline. Turning them into something a studio can trust with production work is still engineering, and that is still where the difficulty lives.

Frequently Asked Questions

Should I use the Unity CLI or Unity MCP? If your agent can run shell commands, call the CLI directly. Unity says those calls are faster and use fewer tokens than MCP. Use unity mcp, the CLI's own MCP mode, for clients that have no shell.

Is Unity MCP deprecated? The MCP server inside the AI assistant package (com.unity.ai.assistant) is deprecated. The CLI's MCP mode, unity mcp, replaces it and is supported. Community MCP servers are not affected.

Is the Unity CLI free? Yes. Unity states that the CLI is free, is separate from Unity AI, and needs no Unity AI subscription. It can also activate a Unity Personal license, with unity license activate.

When was the Unity CLI released? Unity announced it on July 20, 2026. Its release notes list a first 0.1.0 beta on April 4, 2026 and the move to 1.0 betas on June 30. As of November 11, 2026 the latest version is 1.0.0-beta.17, released on November 5, and there is no stable release yet.

Does the Unity CLI work with Claude Code, Cursor or Codex? Yes. Any agent with a terminal can call it, and unity mcp configure supports 16 MCP clients, including Claude Code, Cursor, Codex, VS Code and Windsurf.

Working with Vindler

Vindler designs and ships custom AI workflows for game studios, wiring the engine, the asset pipeline, the test rig, and the product backlog into a single agent-driven system built around the studio's actual stack and process. A large part of that work is the tailored MCP layer described above: choosing which operations to expose, shaping what they return, and tuning the result for latency and token cost against a real pipeline rather than a demo.

If you run a game studio and want to talk about where the Unity CLI fits in your stack, how to migrate off a community MCP server, or how to build a tailored tool surface that keeps your agent runs fast and cheap at production volume, book a call.

If you want more on how we approach AI engineering in production, see our case studies or contact us directly.

Sources

Unity's announcement, Meet the Unity CLI: manage Unity from your terminal, July 20, 2026. The Unity CLI documentation and release notes. The Unity Discussions thread, Announcing the Unity CLI: A new way to connect your tools and agents, where the bug reports, benchmarks, and Unity engineering responses quoted above were posted.

For the November 2026 update: Unity's page on the CLI as the replacement for the in-Editor MCP server, the Unity CLI release notes, the Pipeline package changelog, the FAQ on Unity's AI tools page, and the unity-cli skill in Unity's skills repository. Star counts are from the GitHub API on November 11, 2026.