dev: Unity MCP editor discovery heartbeat expires after about 120 seconds

[wallstop]

Problem

The authenticated Unity MCP HTTP bridge remains healthy, but editor-backed tools become unavailable when the host editor's discovery record stops refreshing. This blocks the repository's required local Unity compile/test loop even though npm run unity:mcp:probe continues to succeed.

Reproduction

Host observed on 2026-08-15:

• Unity 6000.4.6f1 on macOS
• host project: /Users/wallstop/Code/Packages
• bridge endpoint: http://host.docker.internal:9017/mcp
• discovery record: /Users/wallstop/.unity/mcp/connections/bridge-bb0f8bda-58495.json
• editor PID: 58495
• named pipe: /tmp/unity-mcp-bb0f8bda-58495

1. npm run unity:mcp:probe completes the MCP handshake.
2. While the discovery record is fresh, Unity_ManageEditor GetState, Unity_ManageScene GetActive, and a read-only Unity_RunCommand succeed.
3. The record's mtime stops advancing.
4. At roughly 120 seconds of age, editor-backed calls return:
   Unity not detected (no fresh discovery files found)
5. The HTTP probe still succeeds because transport/authentication are independent of editor discovery.

A safe Assets/Refresh from a clean main-stage editor triggered a domain reload, but discovery disappeared again before fresh-assembly proof or focused tests could launch. Restarting/configuring the HTTP bridge alone does not recreate the editor record. The editor continued reporting about 53 hours of uptime, confirming it had not been fully restarted.

Expected behavior

While the Unity editor and MCP integration are alive, the discovery record should refresh continuously across idle periods and domain reloads. Editor-backed calls should not become unavailable while the HTTP bridge remains connected to a live project.

Safety constraints

• Do not manually touch or rewrite the discovery JSON; that could bless a stale PID/pipe.
• Before refresh/restart, confirm every scene is clean, the main stage is active, and the editor is not playing, compiling, or updating.
• The safe immediate recovery is a full editor quit/reopen, then verify the record mtime continues advancing beyond two minutes.

Investigation follow-up

If a full restart reproduces the frozen mtime:

1. inspect Unity Console and Editor.log for discovery-writer failures;
2. record the installed Unity AI Assistant / MCP relay package versions;
3. determine whether the editor-side InitializeOnLoad heartbeat survives domain reload;
4. report upstream with the record mtime, PID/pipe, and package versions.

This is separate from #308: that issue tracked Unity's repeating native audio lock assertion, not discovery expiry.

[wallstop]

Recovery evidence from session 215 (2026-08-15 UTC): without changing the HTTP bridge configuration, Unity discovery became available again in the same long-lived editor process (startup time remained about 53.6 hours). After a clean-scene/main-stage preflight, Assets/Refresh compiled the changed test assemblies at 01:32 UTC. Unity MCP then completed 23 runtime benchmark-contract tests and 119 editor benchmark-harness tests (160.45 seconds), and a post-test command still succeeded with the scene clean and the editor idle. This proves the bridge/test loop can recover and remain reachable beyond the previously observed ~120-second cutoff, but it does not establish that the editor-side heartbeat defect is permanently fixed; keeping this issue open for recurrence/package-writer evidence.