# Meet the Unity CLI: manage Unity from your terminal > Source: > Published: 2026-07-20 00:00:00+00:00 *In this 25-second clip, a developer hands an AI agent a plain-English bug report: "the player sometimes falls through the floor." The agent uses unity command eval to inspect the live scene, finds a collider disabled at runtime, re-enables it, and re-enters Play mode to confirm the fix, observing the running game, acting on it, and verifying the result itself, with no copy-pasting of console output.* # Meet the Unity CLI: manage Unity from your terminal ## TL;DR **Available now**: the** Unity CLI**is a standalone*unity*binary for managing and interacting with editors, modules, projects, and auth from the terminal. No UI needed; install via command line.- Built for automation: structured JSON/TSV output, clear exit codes, non-interactive installs, and service-account auth for CI. **Also available today**: the experimental*com.unity.pipeline*package lets the CLI drive a running Editor, or a dev Player build, over a local API. You can expose your own commands with a*[CliCommand]*attribute.*unity command eval*runs C# code live inside a running Editor or Player and returns the result, with no project-level recompile or domain reload required.- Together, they allow AI agents to operate Unity: observe a live project, act on it, and verify the result. More and more of development happens in the terminal: in scripts, in CI, and increasingly in the hands of AI agents. Today Unity meets you there. The **Unity CLI** brings Unity to the terminal at every level: install and manage editors with one binary, drive a running Editor from a script, and even execute live C# inside your project with no recompile. It's one single, fast unity command, and each layer goes further than the last: the CLI manages Unity, the Pipeline package drives it, and eval reaches inside it. Both the CLI and the Pipeline package are available today. Before we dig into things, let’s take a look at what is possible when these features come together: ## What is the Unity CLI The CLI ships as a single self-contained binary. There are no dependencies to install, and installation adds itself to your PATH: simply run it as *unity*, and update it in place with *unity upgrade*. Beyond editors and projects, it also handles modules and authentication, so a fresh machine needs nothing else. Because it's a native binary, it starts quickly, whereas the old Unity Hub headless path (*-- --headless*) took noticeably longer. This gap adds up across the dozens of calls a script or agent makes per job. ## Get started Install it with your platform’s package manager: ``` # 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 ``` *(Note: Support for standard package managers like brew, winget and apt is coming soon. Refer to the CLI documentation for the latest.)* Explore what's available: ``` unity --help ``` Installing an editor with the modules you need is a one-liner: ``` unity install 6000.2.10f1 -m android ios webgl ``` From there, commands read the way you'd expect: *unity editors* to see what's installed, *unity open* to launch a project with the right editor resolved, and *unity auth login* to sign in. Not sure which module IDs a version has? *unity modules list 6000.2.10f1* has you covered. ## Built for automation The CLI was built to live inside automation, not just an interactive shell. Every command can emit structured output you can pipe straight into your tooling: ``` unity editors --format json unity editors --format tsv ``` Errors go to *stderr*, results to *stdout*, and exit codes follow a simple contract (*0* success,* 1* error, *130 *cancelled), so failures are easy to catch in a pipeline. For unattended installs, skip every prompt: ``` unity install 6000.2.10f1 -m android ios --accept-eula --yes ``` On a headless build agent, it authenticates with a service account via environment variables. No browser, no manual step. And *unity doctor* diagnoses environment, credential, and configuration problems. ## Talking to the Editor Managing installs is only half the story. The Unity CLI can also drive a *running* Editor. Once added to a project, *com.unity.pipeline* lets a running Editor receive commands from the CLI entirely on your machine. It works with Unity 6.0 LTS and newer, and turns the Editor into a programmable automation target for scripts, CI jobs, and agentic tools. Adding it to a project is a single command: ``` unity pipeline install ``` You can check which of your projects have it installed with *unity pipeline list*. With the package in place, you can execute registered commands against a connected Editor (or even a Player runtime) directly from the terminal: ``` # List the commands a connected Editor exposes unity command # Run one of them unity command ``` Those commands aren't a fixed set. Any static method in your project becomes one by adding a *[CliCommand]* attribute, with *[CliArg]* on its parameters: ``` 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, with no registration step. *unity command greet --name World* runs it against the connected Editor and hands back the result. The Pipeline package is available today. It is currently **experimental**, so expect it to evolve. It lets you automate what used to require a human in the Editor: triggering imports, running tests, custom tooling. It doesn't stop at the Editor. Drop its runtime component into a development build and your *running game* exposes the same kind of API. Point the CLI at it with *unity command --runtime * to pull live logs, query runtime status, or hot-reload code in a build that's already playing. It's localhost-only and off by default (for dev and QA builds, never production), but it turns a running Player into something a script, test rig, or AI agent can drive in a live runtime instance. Unity CLI<->running Editor via com.unity.pipeline ### Execute C# scripts with *eval* Registered commands cover the operations you've anticipated. *unity command eval* covers the ones you haven't. It evaluates an arbitrary C# expression *inside* a running Editor and hands you back the result: a live Read-Eval-Print Loop (REPL) into your project, from the terminal. ``` unity command eval "return Application.version;" unity command eval "return UnityEditor.EditorApplication.isPlaying;" unity command eval "var s = Application.dataPath; return s.Length;" --json unity command eval_file "path/to/script.cs" ``` It's compiled with Roslyn and run on the Editor's main thread, so it reaches any engine or editor API your project can, and the same *--runtime* flag aims it at a live Player. Because that power cuts both ways, eval is gated behind a security token. No predefined command, no plugin, no recompile: if you can express a question in C#, you can ask a running Unity instance. The advantage is speed. The usual change-and-check cycle (edit, recompile, relaunch) costs seconds at best; *eval *answers in milliseconds against an instance that's already up. Across the many calls a script or an agent makes in a session, that difference adds up, and it’s exactly what gives an AI agent a tight feedback loop instead of a slow one. ## A foundation for AI-assisted development These pieces (a scriptable CLI, a programmable Editor, and a live REPL) add up to more than convenience. They’re what make the demo at the top of this post possible, and they turn Unity into an environment an AI agent can actually work in. AI coding assistants are good at writing code and content. They've historically struggled with everything around that: running the project, seeing what broke, trying again. An assistant can generate a gameplay script but can't run the tests to see if it works. The Unity CLI and Pipeline layer close that gap. Two properties make the difference. First, the CLI speaks a language agents understand: structured JSON and a predictable exit-code contract mean a model gets clean, parseable results instead of scraped console text. The same qualities that make it reliable in CI make it reliable as a tool an agent calls. Second, the Pipeline package makes the Editor self-describing: run *unity command* with no arguments and a connected Editor reports the operations it exposes. An agent discovers what it can do at runtime instead of relying on a hardcoded list. And because commands are registered with simple attributes, your team can expose project-specific operations as agent-callable tools. This means that each registered command maps naturally into the kind of tool an agent already knows how to invoke. Put those together and you get a real feedback loop: an assistant can open the project, apply a change, run the tests, enter Play mode to check behavior, read the result, and decide what to do next, with no human relaying output back and forth. That's the shift from an assistant that *suggests* to one that can *verify*. It's also a natural fit for emerging agent standards: each registered command maps onto the kind of tool a function-calling model or MCP server already knows how to invoke. And there's no fixed list of what an agent can do. Because *eval *reaches whatever API your project can call, an agent's capability surface is the same as Unity's: rendering, physics, animation, the asset database, the Editor itself, plus everything your own code adds. That reach is the result of more than a decade of API work, and an agent gets it without any extra integration. We're at the beginning of this, and the primitives are already here today. If you're building AI-assisted tooling for Unity, the Pipeline package is where to start. ## How it relates to Unity’s AI offerings If you use Unity’s AI offerings, such as the in-Editor assistant suite, this is the layer underneath it. Unity’s AI is the part that reasons about your project and decides what to do. The CLI and the Pipeline package are the execution surface that carries those decisions out: fast, local, and token-gated. The same surface is open to any agent, whether that's Unity's own tooling routing through its MCP server, a third-party assistant, or a script you write yourself. Unity’s AI is one consumer of it, not a replacement for it. ## Available now The Unity CLI is here. Install it, run *unity --help*, and fold it into your next build script or CI job, or automate it with an agent. The [documentation](https://docs.unity.com/en-us/unity-cli) has the full command reference. Tell us what you build; your feedback shapes where it goes next. *Safe harbor statement: This roadmap represents Unity's current intentions for the development of our product suite. It is provided for informational purposes only and is not a commitment to deliver any specific feature or functionality. The information provided is subject to change at any time, and Unity makes no guarantees regarding the content, timing, or nature of any future releases. User should not rely on this roadmap for any business-critical decisions.*