Reported by Illia Komendantov (Core Pipeline / Automated PR Testing / Explorer team).
Slack thread: https://unity.slack.com/archives/C0AUDHS49UJ/p1788513906115499
Full report attached to that thread: "Unity CLI: Explorer's Remaining Gaps".
Summary
A command whose main-thread crossing runs longer than the configured timeout budget is reported back to the caller as Main thread operation timed out after <n>ms — even though the operation itself completes successfully in the Editor. Found on a heavy ImportPackage call. This is a false negative: the caller is told the operation failed when it didn't.
Distinct from the default value being too low (that's [Internal link], already fixed) — this is about the timeout mechanism misreporting outcome, not about which default it uses. Also distinct from [Internal link] (503s / readiness probing), which is about the Editor not being ready yet at startup, not this misreport-after-success case.
Secondary note
The default 30s unity command budget is also low for real Editor work; Explorer passes an explicit 120s on every call as a workaround. Worth reconsidering the default separately from the misreport bug above.
Ask
When a main-thread operation exceeds its timeout budget but subsequently completes, don't report it as failed — either wait for and report the real result, or make the timeout response unambiguous about "still running" vs "failed".