Blender-MCP error, identified by me and Claude

Title: Server accepts connections but never processes commands on Windows (Blender 5.2 LTS) — _handle_client never logs "Queued command"

Environment: Windows, Blender 5.2.1 LTS, addon freshly reinstalled via uvx blender-mcp install-addon

Symptoms:

Server starts cleanly (BlenderMCP server started on localhost:9876), and accepts client connections (Connected to client: (...), Client handler started). The client handler's recv()/json.loads() buffer-accumulation loop in _handle_client() never successfully parses a command — the print(f"Queued command: {command.get('type')}") line never fires, even with a live, connected client sitting for 60+ seconds. self.command_queue.qsize() stays at 0 indefinitely. Client eventually disconnects/times out with no error ever printed on the Blender side. Reproduced consistently across multiple full Blender restarts, multiple fresh bridge (blender-mcp.exe) process restarts, and after confirming only one server instance / one client is involved (no port or process conflicts).

Separately noticed: in BlenderMCPServer.start(), immediately after calling bpy.app.timers.register(self._drain_command_queue, persistent=True), a subsequent call to bpy.app.timers.is_registered(self._drain_command_queue) returns False. This may be a false negative caused by bound-method identity (each self._drain_command_queue attribute access creates a new bound-method object), which could make the if not bpy.app.timers.is_registered(...) guard in start() behave unreliably, or could indicate the timer really isn't registering. Worth storing a single bound reference (e.g. self._drain_cb = self._drain_command_queue in init) to rule this out.

Suspicion: the client-side send in the blender-mcp bridge package may be sending something (framing, multiple messages, or extra bytes) that this simple accumulate-and-retry-json.loads() parser in _handle_client() can't handle, since no length-prefix or delimiter is used.