Environment
- MCP for Unity from git
#main (PackageCache hash 73eb27aecc), HTTP transport
- Unity 2022.3.62f3, macOS 26.2 (Tahoe), driven headlessly by an MCP client (Claude Code) while the editor is mostly unfocused/background
- Large project (~3.8K EditMode tests), frequent git branch switches → repeated full recompiles + domain reloads
Symptom 1 — bridge session drops after domain-reload churn, re-registers only on focus
After several consecutive branch-switch → full-recompile → domain-reload cycles in one editor session, tool calls start failing with Unity session not available; please retry and the mcpforunity://instances resource reports instance_count: 0. The editor process is alive and its update loop is running (Editor.log shows the MCPForUnity connection-section UI ticking).
Waiting does not recover it (observed >5 minutes). Focusing the editor window recovers it — the instance re-registers within ~60s of osascript … activate and everything works again.
Earlier in the same sessions we also saw the milder shape: refresh_unity responding Refresh recovered after Unity disconnect/retry on nearly every call — i.e. the session was silently dropping and being re-established per-call before it eventually stopped recovering at all.
Related: #643 reported "no session" after client reconnect over HTTP (closed). This report differs: no client reconnect involved — the drop correlates with editor-side domain reloads while unfocused, and recovery correlates with editor focus.
Symptom 2 (context / interaction) — queued compile never ticks while unfocused, MCP waits time out
With the editor unfocused, after a NuGetForUnity restore whose .dll.meta import hit a SourceAssetDB mtime mismatch (Import Error Code:(4)), EditorApplication.isCompiling stayed true for ~20 minutes with near-idle CPU: refresh_unity(wait_for_ready) timed out repeatedly, run_tests returned busy/compiling, and execute_code (which still worked) confirmed isCompiling=true and that no new assemblies had loaded. CompilationPipeline.RequestScriptCompilation() via execute_code queued a compile that also did not run — until the editor was focused, at which point it completed immediately (0 errors).
Mentioning it here because the two together make unattended/headless-style driving of a background editor unreliable, and because refresh_unity's wait loop might be able to detect the "compile queued but not ticking + editor unfocused" state and surface a actionable hint (or nudge the editor) rather than timing out generically.
Repro sketch
- Editor open but unfocused (another app foreground) on a large project, HTTP transport.
- Drive several branch switches with full recompiles + domain reloads via MCP (
refresh_unity force + compile request each time).
- Observe per-call
recovered after Unity disconnect/retry escalating to persistent instance_count: 0.
- Focus the editor → instance re-registers, tools work.
Ask
- Bridge re-registration after domain reload appears to depend on an editor tick/callback that doesn't fire (or fires too rarely) while the editor is unfocused on macOS — could registration be made focus-independent (e.g. background-safe retry timer), or at least surfaced distinctly from a dead server?
- A
hint on the failure path ("editor may be unfocused — focus to recover") would save users a lot of head-scratching; we lost real time to this across several sessions before isolating the focus correlation.
Happy to provide fuller Editor.log excerpts for either symptom.
Environment
#main(PackageCache hash73eb27aecc), HTTP transportSymptom 1 — bridge session drops after domain-reload churn, re-registers only on focus
After several consecutive branch-switch → full-recompile → domain-reload cycles in one editor session, tool calls start failing with
Unity session not available; please retryand themcpforunity://instancesresource reportsinstance_count: 0. The editor process is alive and its update loop is running (Editor.log shows the MCPForUnity connection-section UI ticking).Waiting does not recover it (observed >5 minutes). Focusing the editor window recovers it — the instance re-registers within ~60s of
osascript … activateand everything works again.Earlier in the same sessions we also saw the milder shape:
refresh_unityrespondingRefresh recovered after Unity disconnect/retryon nearly every call — i.e. the session was silently dropping and being re-established per-call before it eventually stopped recovering at all.Related: #643 reported "no session" after client reconnect over HTTP (closed). This report differs: no client reconnect involved — the drop correlates with editor-side domain reloads while unfocused, and recovery correlates with editor focus.
Symptom 2 (context / interaction) — queued compile never ticks while unfocused, MCP waits time out
With the editor unfocused, after a NuGetForUnity restore whose
.dll.metaimport hit a SourceAssetDB mtime mismatch (Import Error Code:(4)),EditorApplication.isCompilingstayedtruefor ~20 minutes with near-idle CPU:refresh_unity(wait_for_ready)timed out repeatedly,run_testsreturnedbusy/compiling, andexecute_code(which still worked) confirmedisCompiling=trueand that no new assemblies had loaded.CompilationPipeline.RequestScriptCompilation()viaexecute_codequeued a compile that also did not run — until the editor was focused, at which point it completed immediately (0 errors).Mentioning it here because the two together make unattended/headless-style driving of a background editor unreliable, and because
refresh_unity's wait loop might be able to detect the "compile queued but not ticking + editor unfocused" state and surface a actionable hint (or nudge the editor) rather than timing out generically.Repro sketch
refresh_unityforce + compile request each time).recovered after Unity disconnect/retryescalating to persistentinstance_count: 0.Ask
hinton the failure path ("editor may be unfocused — focus to recover") would save users a lot of head-scratching; we lost real time to this across several sessions before isolating the focus correlation.Happy to provide fuller Editor.log excerpts for either symptom.