--- title: "Meet the Unity CLI: manage Unity from your terminal" url: https://daily.dev/posts/meet-the-unity-cli-manage-unity-from-your-terminal-oyxu9r6jr source_url: https://unity.com/blog/meet-the-unity-cli type: article source: "Unity" published: 2026-07-20T22:13:44.461Z updated: 2026-07-23T18:22:32.596Z tags: ["game-development", "ai-agents", "cicd", "cli", "unity"] reading_time: 10 upvotes: 40 comments: 3 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Meet the Unity CLI: manage Unity from your terminal **[Unity](https://daily.dev/sources/unity)** · 10 min read · 40 upvotes · 3 comments ## Summary Unity has released a standalone Unity CLI binary that lets developers manage editors, modules, projects, and authentication entirely from the terminal without needing the UI. The CLI supports structured JSON/TSV output, clear exit codes, and service-account auth for CI pipelines. Alongside it, the experimental com.unity.pipeline package enables the CLI to drive a running Unity Editor or dev Player build over a local API. Developers can expose custom commands using a [CliCommand] attribute on static methods. A key feature, unity command eval, runs arbitrary C# code live inside a running Editor via a Roslyn-based REPL with no recompile or domain reload needed. Together, these tools create a tight feedback loop for AI agents to observe, act on, and verify changes in a live Unity project. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 41 comments across hackernews (as of 2026-07-23). **TL;DR:** The community is cautiously optimistic about Unity's new agent-native CLI, welcoming the opening of APIs and editor-decoupled automation, but debates whether direct YAML/filesystem manipulation or a tight live feedback loop is the better approach for LLM-driven game development. **Sentiment:** 40% positive · 40% mixed · 20% skeptical **The case for** - The CLI enables editor-decoupled operations like running unit tests and CI pipelines without a running editor instance. - Opening up APIs via AI/FOMO pressure is seen as a genuine win for developer experience and automation. - The same surface being shared with Unity MCP means third-party agents and scripts can also benefit. - Agent-native CLIs with machine-readable, token-efficient output are viewed as a useful emerging pattern. **The pushback** - Some commenters argue directly manipulating raw Unity scene YAML files is simpler and more effective for LLM automation than going through the CLI. - Letting agents take screenshots for visual feedback is considered unreliable for 3D scene understanding without purpose-trained world models. - Unity has been a laggard in AI adoption compared to Epic/Godot, and this is seen as catching up rather than leading. - The editor's exclusive lock on the project directory remains a pain point for parallel or headless workflows. - The source code appears to be closed-source, which raised questions. **By community** - hackernews (mixed): Commenters appreciate the direction but are split on whether live CLI interaction or raw filesystem manipulation is the right model for LLM-driven Unity development, with several practical workarounds and comparisons to Godot already being discussed. **Hottest debate:** Whether LLM agents should interact with Unity via a live CLI/screenshot loop or by directly editing raw YAML scene files on the filesystem. **Open questions** - Will the CLI support decoupled type-checking and unit test execution without a running editor? - Is the Unity CLI open-source, and where can the source be found? - How long does headless Unity take to boot, making it practical for CI? - Will Unity release official Docker images of the editor to simplify build machine setup? **Highlights** > > 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. I played around with automating Unity with LLMs for a while. The ability to do this would have been very compelling to me at the beginning. At this point, I think the more productive way for frontier models to interact with a unity project is to directly manipulate the raw scene files. They are not binary. These files are effectively YAML documents that you can parse, grep and patch just like any other text/code document. The key is to build the tools around these in the same way you would build tools around an agent that can read and manipulate multi-megabyte json documents. It's the same pattern. Working with a unity project from the filesystem is so much simpler than working with one through all the APIs/CLIs/etc. The files in the unity project path represent 100% of the required information, so the editor feature surface is not relevant unless you are explicitly trying to build editor tooling. I spent a solid month fighting the domain reload dragon only to realize it didn't fucking matter. I can just wait for the domain reload. As long as the work iteration step size is meaningful, this is not a huge deal. > — [bob1029 on hackernews · 1 comments](https://news.ycombinator.com/item?id=49020587) > > I think the more productive way for frontier models to interact with a unity project is to directly manipulate the raw scene files. I disagree. Even moreso than webdev, gamedev benefits from a fast and reliable loop, especially one that can capture realtime state and screenshots. It's the difference between having a new well tested mechanic in your game next morning and giving up after a week of debugging. Agents will work around slow iteration loops perfectly fine given enough time, but when you're shipping 20 core things in your game each day, the agent's test harness becomes the bottleneck. IMO it's worth it to spend a day or two to make sure your test loop is tight, it will pay dividends. Not saying Unity is great at playing ball here though. Hopefully their new effort helps. > — [avaer on hackernews · 1 comments](https://news.ycombinator.com/item?id=49020699) > Honestly one of the major upsides of all the AI hype is the FOMO overtook the desire to wall your garden and all these APIs are opening up. I had to struggle for years managing Unity editor installs by hand and then through the headless mode in Hub. It would be nice if they finally released docker images of the editor so you could more easily spin up build machines too. Oh uh, the AI needs it... yeah. Its for AI. > — [jayd16 on hackernews](https://news.ycombinator.com/item?id=49023177) > Great. For my game [1] I have long had the capacity to compile a separate commandline application using unity code [2]. This lets me do benchmarks and unit tests on the core chess AI code without the editor. However I've had to maintain a separate second unit test suite that I can only run in the editor manually if any unity specific code is involved. Naturally, it's run far less often. This new unity cli doesn't replace that design, since it's important to me that my core chess variant AI code remains a project on its own, totally independent of unity. But it does mean lots of my utilities like my second unity test, which normally require clicking a button in the editor, can now be run without the editor. Excellent! Making a 2d chess variant game means almost all unity editor features just get in my way. [1] https://www.chesscraft.ca [2] https://youtu.be/U4xBLTpZ9Xo?si=Gd2aAWKvLqBVBU66 > — [zulban on hackernews](https://news.ycombinator.com/item?id=49021116) > I wouldn't be so sure about that. Have you actually tried? You might be surprised. Screenshots are a hell of a big baby to be throwing out with the bathwater. The structured data this cli returns is great, but screen snapshots can be extremely useful too, both together. Editing raw yaml files can be tricky, so you do want a formal editing api you can go through, that is extensible for your own component property getters and setters and apis and editors, that correctly maintains all the constraints and dependencies, instead of just letting the LLM hot dog it with your raw yaml files by peeking and poking. > — [DonHopkins on hackernews](https://news.ycombinator.com/item?id=49023674) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=48995712) · 57 points · 39 comments - [hackernews](https://news.ycombinator.com/item?id=48989825) · 1 points · 2 comments ## Community discussion Top comments from developers on daily.dev. **@foult080** · 3 upvotes > Every day, we're getting more and more work done at the terminal, and that's great! **@trevorsuna** · 1 upvotes > Structured output, clear exit codes, and service-account auth are exactly what a useful CI tool needs. The live C# eval is powerful too, though I’d put tight guardrails around it in shared environments. **@renchon** · 0 upvotes > finally i can get rid of the bloat that is the hub --- Tags: [#game-development](https://daily.dev/tags/game-development), [#ai-agents](https://daily.dev/tags/ai-agents), [#cicd](https://daily.dev/tags/cicd), [#cli](https://daily.dev/tags/cli), [#unity](https://daily.dev/tags/unity) [View this post on daily.dev](https://daily.dev/posts/meet-the-unity-cli-manage-unity-from-your-terminal-oyxu9r6jr)