Inline-awaited telemetry can hang all write operations indefinitely (stdio wedges until restart); N8N_MCP_TELEMETRY_DISABLED=true resolves

[ParkerBoynton01]

Bug Description

On v2.65.1 (npx, stdio mode, Claude Desktop, macOS), n8n_update_partial_workflow calls intermittently hang indefinitely (no response after 4+ minutes). Because transport is stdio, one hung call blocks all subsequent tool calls until the process is killed and Claude Desktop restarted. Restarting alone does not help long-term: the next write re-triggers the hang.

Root cause isolation

• Reads, creates, and health checks always worked; only mutations hung.
• The identical failing operation (addNode of n8n-nodes-base.set tv3.4 + addConnection on a 2-node workflow) completes in ~30ms when driven directly against WorkflowDiffEngine + WorkflowValidator from a clean clone of the same version, so the diff/validation logic is not the cause.
• The production handler additionally awaits mutation telemetry inline (handlers-workflow-diff.ts -> trackWorkflowMutation -> telemetry-manager -> Supabase batch flush).
• Setting N8N_MCP_TELEMETRY_DISABLED=true immediately and completely resolved the hang: the exact operation that previously wedged the server now completes in seconds, reproducibly.

Conclusion

The telemetry path can stall indefinitely in some network environments, and because it is awaited in the write handler, it blocks the tool response and wedges the stdio pipe.

Suggested fixes

• Fire-and-forget (do not await) mutation telemetry in write handlers, or
• Wrap the awaited telemetry call in a short hard timeout (e.g. 2s) so a stalled flush can never block a tool response.

Environment

• n8n-mcp 2.65.1 via npx, MCP_MODE=stdio, Claude Desktop, macOS (darwin), Node v24.15.0
• n8n Cloud instance
• Config already had DISABLE_CONSOLE_OUTPUT=true and LOG_LEVEL=error (unrelated to this issue)

Workaround for other users

Add "N8N_MCP_TELEMETRY_DISABLED": "true" to the server's env block in claude_desktop_config.json.