Problem
Several JSON-RPC methods intentionally execute on the listener/current thread instead of being marshaled to the Unity main thread, but the code does not enforce or document that those handlers must avoid Unity APIs.
Evidence
Editor/MCPServerMethods.cs:116-122 fast-paths get_server_status, attach_existing_session, wait_for_asset_import_idle, and wait_for_editor_idle through ExecuteMethod on the current thread.Editor/MCPServerMethods.Status.cs:28-69 implements get_server_status and currently reads Application.unityVersion as part of the response.Editor/MCPServerMethods.Sync.cs:42-90 implements the wait methods off-thread using cached state and sleep loops.
Impact
Unity APIs are generally main-thread-only. A future edit to one of these handlers can accidentally add unsafe UnityEditor/UnityEngine calls that run on the listener thread, causing exceptions or racey editor behavior. The current get_server_status already mixes cached state with Application.unityVersion, so the contract is not obvious.
Suggested fix
Make the fast-path contract explicit and enforce it: keep handlers limited to thread-safe cached state, move unsafe fields behind main-thread dispatch, or split fast health checks from rich editor status. Add comments/tests around the allowed off-thread surface.
Source report
Imported from audit report item: security (8) / Editor/MCPServerMethods.cs:117.
Problem
Several JSON-RPC methods intentionally execute on the listener/current thread instead of being marshaled to the Unity main thread, but the code does not enforce or document that those handlers must avoid Unity APIs.
Evidence
Editor/MCPServerMethods.cs:116-122fast-pathsget_server_status,attach_existing_session,wait_for_asset_import_idle, andwait_for_editor_idlethroughExecuteMethodon the current thread.Editor/MCPServerMethods.Status.cs:28-69implementsget_server_statusand currently readsApplication.unityVersionas part of the response.Editor/MCPServerMethods.Sync.cs:42-90implements the wait methods off-thread using cached state and sleep loops.Impact
Unity APIs are generally main-thread-only. A future edit to one of these handlers can accidentally add unsafe UnityEditor/UnityEngine calls that run on the listener thread, causing exceptions or racey editor behavior. The current
get_server_statusalready mixes cached state withApplication.unityVersion, so the contract is not obvious.Suggested fix
Make the fast-path contract explicit and enforce it: keep handlers limited to thread-safe cached state, move unsafe fields behind main-thread dispatch, or split fast health checks from rich editor status. Add comments/tests around the allowed off-thread surface.
Source report
Imported from audit report item:
security (8)/Editor/MCPServerMethods.cs:117.