Copyright © 2026 Unity Technologies
Reported by Illia Komendantov (Core Pipeline / Automated PR Testing / Explorer team).
Slack thread: https://unity.slack.com/archives/C0AUDHS49UJ/p1788976449788599
Full report: "Unity CLI 1.0.0-beta.9 + com.unity.pipeline 0.6.0-exp.1 — new findings", §3 — new in this release, flagged before the reporter has hit it.
Runtime/Unity.Pipeline.asmdef in com.unity.pipeline 0.6.0-exp.1 adds a reference to Unity.InputSystem:
"references": ["Unity.InputSystem", "Unity.Pipeline.IlInterpreter"], "defineConstraints": [], "versionDefines": [ {"name": "com.unity.modules.unitywebrequest", "expression": "1.0.0", "define": "UNITY_2022_3_OR_NEWER"} ]
The reference is unguarded — defineConstraints is empty, and the one versionDefines entry is unrelated to it. Meanwhile package.json's dependencies are byte-identical to 0.5.0-exp.1 and do NOT include com.unity.inputsystem.
On a project without the Input System installed, Unity's own handling per Editor/Mono/Scripting/ScriptCompilation/EditorCompilationInterface.cs:163 is: "The assembly for Assembly Definition File '
{0}' will not be loaded. Because the assembly for its reference '
{1}' does not exist on the file system." If that's what happens here, Unity.Pipeline fails to load entirely — no pipeline server at all — on any project lacking Input System. That would also make the remedy for the CLI's own version-gate refusal ([Internal link]) a dead end on those projects: unity pipeline upgrade to 0.6.0-exp.1 would remove the server the user is trying to fix.
"We have not confirmed the failure, and want to be straight about that: confirming it means upgrading the Editor our test fleet depends on, and the downside is losing both the CLI route and the HTTP route at once. We deferred the upgrade." They note the rest of 0.6.0-exp.1 looks safe from a CLI-consumer's side: CliCommandAttribute.cs/CliArgAttribute.cs are byte-identical to 0.5.0, and the Unity.Pipeline assembly name / Unity.Pipeline.Commands namespace are unchanged.
Should be cheap to check on any project without com.unity.inputsystem: either declare the dependency in package.json, or guard the Unity.InputSystem reference in the asmdef (e.g. a defineConstraints/versionDefines gate keyed on the Input System package being present) — the same shape as [Internal link]'s unguarded-reference defect, just in the asmdef's references array instead of a C# using.
[Internal link] (com.unity.pipeline CS0234 — unguarded reference to something the package doesn't declare; same shape, different mechanism).
Issues you vote on will appear here