[BUG] claude.ai tldraw MCP app — exec tool call times out after 30s even though edits land on the canvas

Open 💬 1 comment Opened Jun 20, 2026 by Nagell

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:

  1. The model never receives the canvasId that 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.

  1. Per the tool description, omitting canvasId creates 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:exec should return its result (including canvasId on 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

  1. In a claude.ai conversation, ask Claude to draw something using the tldraw MCP App (e.g. "draw me a duck on tldraw").
  2. Claude calls tldraw:exec with shape-creation code, no canvasId (first call, none exists yet).
  3. 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).
  4. Ask Claude to clean up a leftover test shape. Claude calls tldraw:exec again (still no canvasId, since none was ever returned in step 2).
  5. 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.
  6. 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

  1. Response completion handshake between the tldraw MCP App and the

claude.ai client for the exec channel specifically

  1. Whether the 30s timeout is hardcoded for this channel and too short for

canvas operations

  1. Whether parameterless exec calls (no canvasId) are being treated as

"create new canvas" even when the model's intent was clearly to continue
editing an existing session

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗