Add per-call timeout parameter to execute_code

[jasoncbraatz]

First off — thanks for putting this server together. It's been load-bearing in my pre-CNC validation workflow (I render Maya previews of CNC'd parts before committing physical fabrication time), and the multi-session + Qt-server-on-demand design is really nice to work with. The zero-Maya-side-setup story in particular is excellent. ❤️

The problem

Long-running operations in Maya (Arnold renders, large simulations, heavy mesh ops, batch processes) currently hit the client default timeout — 60.0 set in SessionManager._add_session — and raise:

MayaExecutionError: Timeout waiting for Maya response

This happens inside _send_receive, where asyncio.wait_for(reader.read, timeout=self.timeout) aborts after 60 s even though Maya itself is happily processing the command. The work completes in Maya, but the client connection is lost, so the result is unreachable.

Repro (in a Maya session connected via this server):

# Anything that exceeds 60 s
import maya.cmds as cmds
cmds.arnoldRender(camera="myCamShape", width=2048, height=1536, batch=False)

For a typical Arnold scene of moderate complexity, this is 60–180 s and reliably trips the timeout.

The fix

Add an optional per-call timeout: float | None = None parameter to the execute_code MCP tool, thread it through BaseMayaClient.execute_code and _send_receive, and use it as the asyncio.wait_for deadline when provided. Default behavior is unchanged.

# Quick query: implicit short timeout
await execute_code("cmds.ls(type='mesh')", result_type="JSON")

# Long render: explicit longer timeout
await execute_code(render_code, timeout=600.0)

Both MayaClient (native commandPort) and MayaQtClient (Qt server) are updated. Inside each _send_receive:

effective_timeout = timeout if timeout is not None else self.timeout

Files changed

• src/maya_mcp_server/server.py — new timeout parameter on the execute_code MCP tool, passed to client.execute_code. Docstring updated.
• src/maya_mcp_server/client.py — abstract _send_receive signature, both concrete _send_receive implementations, and BaseMayaClient.execute_code updated. Both asyncio.wait_for calls now use effective_timeout.
• tests/test_client.py — two existing tests updated to assert timeout=None is present in call args; two new tests added: test_execute_code_passes_timeout_override and test_execute_code_default_timeout_is_none.

Tests

All 131 tests pass:

$ pytest tests/ -q
...........................................................              [100%]
131 passed in 0.15s

Caveats / future work

• This only addresses the server-side timeout. The MCP client (e.g. Claude Desktop, Claude Code) may impose its own per-request timeout — typically ~60 s — which can still hit before the server-side wait_for triggers. Users with very long operations may also need to bump their MCP client's request timeout, or we can layer in Context.report_progress(...) notifications in a follow-up to keep the connection alive over long renders. Happy to do that as a separate PR if you'd like.
• The fix is intentionally surgical and backward-compatible — no breaking changes, no new dependencies. Existing callers continue to use self.timeout as before.

Discovered this while building a walnut CNC enclosure where I use Maya/Arnold for pre-fabrication visual validation. Glad to chip back to a tool that's already saved me a lot of CNC hours. Let me know if you'd like me to adjust anything — happy to iterate.