[BUG] claude.ai tldraw MCP app — exec tool call times out after 30s even though edits land on the canvas
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Every call to the tldraw:exec tool (tldraw MCP App, third-party MCP App tag)
fails client-side with a 30-second callback timeout — but the edits described
in the call are actually applied to the canvas and visible to the user. The
widget renders correctly; only the tool-call completion/acknowledgment never
reaches the model.
This produces two compounding problems:
- The model never receives the
canvasIdthat the tool is supposed to
return on creation, since every response times out before any payload
arrives. Without a canvasId, the model can't reliably target the same
canvas for follow-up edits.
- Per the tool description, omitting
canvasIdcreates a brand-new blank
canvas rather than editing the existing one. So a later "fix this" call —
made because the model never knew the right ID to target — actually wiped
out the working canvas from the user's point of view ("now it's gone, no
preview anymore").
This looks like the same failure class reported in #53030 (visualize MCP
app: widget renders, then the tool call fails post-render) — different MCP
App, same symptom shape: render/apply succeeds, completion handshake back to
the client does not. Worth checking whether these share a root cause in how
claude.ai's MCP App client handles tool-call completion generally, rather
than something specific to either app's server.
What Should Happen?
tldraw:execshould return its result (includingcanvasIdon first
creation) within a reasonable timeout, OR
- if the underlying action genuinely takes longer than 30s, the timeout
should be configurable/longer for this channel, consistent with how other
MCP tool calls are handled, OR
- at minimum, on timeout the client should not treat the call as a clean
failure when the action demonstrably succeeded — successive omitted-
canvasId calls should not silently spawn new blank canvases that replace
the one the user is looking at.
Error Messages/Logs
Exec failed: Callback timed out after 30000ms for channel "exec"
request_id: req_011CcF7wN2WGgekbtoCYPE1U
Exec failed: Callback timed out after 30000ms for channel "exec"
request_id: req_011CcF7z3qD8zEXHw82YfSRp
Exec failed: Callback timed out after 30000ms for channel "exec"
request_id: req_011CcF82TKeCEd36PqfTt7XB
Exec failed: Callback timed out after 30000ms for channel "exec"
request_id: req_011CcF892cY1LMN81ryQTH8U
Four consecutive calls, all identical 30000ms timeout, across both shape-
creation and shape-deletion operations.
Steps to Reproduce
- In a claude.ai conversation, ask Claude to draw something using the tldraw MCP App (e.g. "draw me a duck on tldraw").
- Claude calls
tldraw:execwith shape-creation code, nocanvasId(first call, none exists yet). - Tool call fails with the timeout above — but the widget that renders shows all shapes correctly applied (confirmed via screenshot: full duck illustration with body, head, eye, beak, legs, and feet all present).
- Ask Claude to clean up a leftover test shape. Claude calls
tldraw:execagain (still nocanvasId, since none was ever returned in step 2). - Same 30000ms timeout. The widget now shows an empty canvas — consistent with the parameterless call spinning up a new blank canvas rather than editing the one from step 2, since the client has no way to know the prior canvas's ID.
- User reports the previously-visible duck illustration is gone with no way to recover it in-session.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unsure — first use of the tldraw MCP App in this account, so no prior working baseline to compare against.
Claude Code Version
N/A — reproduced on claude.ai web interface, not the CLI
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Related
- #53030 — claude.ai visualize MCP app, same render-then-fail-to-complete
symptom, different MCP App. Possibly shared root cause in MCP App
tool-call completion handling on the claude.ai client side.
Suggested triage direction
- Response completion handshake between the tldraw MCP App and the
claude.ai client for the exec channel specifically
- Whether the 30s timeout is hardcoded for this channel and too short for
canvas operations
- Whether parameterless
execcalls (nocanvasId) are being treated as
"create new canvas" even when the model's intent was clearly to continue
editing an existing session
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗