Problem
#292 changed the socket wire format to length-prefixed JSON frames. The blender_mcp package published on PyPI (1.8.0 as of writing) hasn't been rebuilt against that change and still sends/expects raw JSON with no length prefix.
Anyone who installs the add-on from main (as the README's "Blender Addon" section instructs) while using the documented uvx blender-mcp client install path hits an immediate, unexplained failure: every command is rejected with invalid frame length in the Blender console, surfaced client-side as WinError 10054 / "Connection closed" (or "Connection closed before receiving any data" once past the first hurdle). There's no error message pointing at the actual cause, so it reads as a broken install rather than a version mismatch.
Root cause
_recv_framed_json reads the first 4 bytes of any incoming message as a big-endian frame-length header. A legacy client's raw JSON payload (starting with {) gets misread as a length of roughly 2 billion bytes, which trips the _MAX_FRAME guard and kills the connection before any real command is processed.
Repro
- Install the add-on from current
main in Blender.
uvx blender-mcp (pulls PyPI 1.8.0).
- Connect — first real command fails with
invalid frame length server-side / WinError 10054 client-side, every time, not just "first command flakiness."
Suggested fix
Opening a PR shortly that adds a one-byte peek to detect which protocol a connecting client is using (a real length header's first byte is always 0x00 for any realistic payload; raw JSON never starts with 0x00) and serves either protocol on the same socket. Verified against both a simulated legacy client and live against the actual PyPI-published client.
Problem
#292 changed the socket wire format to length-prefixed JSON frames. The
blender_mcppackage published on PyPI (1.8.0 as of writing) hasn't been rebuilt against that change and still sends/expects raw JSON with no length prefix.Anyone who installs the add-on from
main(as the README's "Blender Addon" section instructs) while using the documenteduvx blender-mcpclient install path hits an immediate, unexplained failure: every command is rejected withinvalid frame lengthin the Blender console, surfaced client-side asWinError 10054/ "Connection closed" (or "Connection closed before receiving any data" once past the first hurdle). There's no error message pointing at the actual cause, so it reads as a broken install rather than a version mismatch.Root cause
_recv_framed_jsonreads the first 4 bytes of any incoming message as a big-endian frame-length header. A legacy client's raw JSON payload (starting with{) gets misread as a length of roughly 2 billion bytes, which trips the_MAX_FRAMEguard and kills the connection before any real command is processed.Repro
mainin Blender.uvx blender-mcp(pulls PyPI 1.8.0).invalid frame lengthserver-side /WinError 10054client-side, every time, not just "first command flakiness."Suggested fix
Opening a PR shortly that adds a one-byte peek to detect which protocol a connecting client is using (a real length header's first byte is always
0x00for any realistic payload; raw JSON never starts with0x00) and serves either protocol on the same socket. Verified against both a simulated legacy client and live against the actual PyPI-published client.