Meet the Unity CLI

First-party Unity blog post (Etienne Whittom, VP Authoring Platform, 2026-07-20) introducing the Unity CLI — a single self-contained unity binary for driving Unity from the terminal. It’s the concrete shipping of the “open collaborative ecosystem” Unity 7 previewed, and both the CLI and its companion Pipeline package are available now (beta channel) rather than waiting for Unity 7.

Three layers, each reaching deeper

The post frames the tooling as three nested capabilities:

The CLI manages Unity. One native binary (adds itself to PATH, self-updates via unity upgrade) installs and manages editors, modules, projects, and auth — e.g. unity install 6000.2.10f1 -m android ios webgl, unity editors, unity open, unity auth login. Starts fast, unlike the old Unity Hub headless path (-- --headless), which matters across the dozens of calls a script makes.
The Pipeline package drives it. The experimental com.unity.pipeline package (Unity 6.0 LTS+) lets the CLI send commands to a running Editor — or a dev Player build — over a local API. Any static method becomes a command via a [CliCommand] attribute (params via [CliArg]); the Editor is self-describing — unity command with no args lists what it exposes, no registration step.
eval reaches inside it. unity command eval "return Application.version;" runs arbitrary C# live inside a running Editor or Player (compiled with Roslyn, on the main thread — full engine/editor API access), no recompile or domain reload. A REPL into the project from the terminal, answering in milliseconds vs the edit→recompile→relaunch cycle’s seconds. Gated behind a security token because the reach cuts both ways.

Built for automation / CI

Structured JSON/TSV output (--format json), results→stdout / errors→stderr, a simple exit-code contract (0 success, 1 error, 130 cancelled), non-interactive installs (--accept-eula --yes), and service-account auth via env vars for headless build agents. unity doctor diagnoses environment/credential problems. The Player-runtime hook is localhost-only, off by default, dev/QA-only, never production.

The point is AI agents

The post is explicit that the target is agentic development, not just CI convenience. The opening demo: a developer hands an AI agent a plain-English bug report (“the player sometimes falls through the floor”); the agent uses eval to inspect the live scene, finds a collider disabled at runtime, re-enables it, and re-enters Play mode to confirm — observing, acting, and verifying on its own, no console-output copy-pasting. The argument: AI assistants are good at writing code but historically bad at running the project, seeing what broke, and retrying; the CLI + Pipeline close that loop. Two properties make it work — the CLI speaks structured JSON + predictable exit codes (parseable, not scraped console text), and the Pipeline package makes the Editor self-describing, so an agent discovers its callable operations at runtime. Unity ties this to emerging agent standards: each [CliCommand] “maps onto the kind of tool a function-calling model or MCP server already knows how to invoke.”

Where it sits under Unity’s AI

The post positions the CLI/Pipeline as the execution surface underneath Unity’s in-Editor AI assistant suite (Unity AI): Unity’s AI reasons and decides; the CLI carries decisions out — fast, local, token-gated. Crucially the same surface is open to any agent, whether Unity’s own tooling routing through its MCP server, a third-party assistant, or a hand-written script — “Unity’s AI is one consumer of it, not a replacement.”

The same conclusions, reached elsewhere

godot-mcp-toolkit (community, 2026-07-27) independently lands on this page’s two load-bearing ideas: an editor that describes its own callable operations to the agent (Godot’s discover_tools against Unity’s unity command), and token-gated, localhost-only access because live write access to an editor is the dangerous part. Collected as a pattern in engine-agent-surface.

unity-engine · unity-7-roadmap · etienne-whittom · unity-technologies · unreal-engine-5-8 · engine-agent-surface · godot-mcp-toolkit · synthesis