Desktop app redraws every mod render site on any state change, which breaks Buttons and restarts SVG animations

Environment

• Claude desktop app 1.40609.1.0 (Windows, MSIX install), Code tab
• Claude Code 2.1.286
• Windows 11 Pro 10.0.26200

Summary

When a mod writes $.state that only one of its render sites reads, the CLI sends ui_invalidate with an instances list naming just that site. The desktop app drops that list and re-asks and rebuilds every render site of the session.

For a mod with a per-second value in one site (here a cache countdown in SessionMode), every other site it draws (here an AbovePrompt band) is rebuilt from scratch every second. That causes two visible bugs:

1. Buttons in the other sites stop working. Each fresh evaluation gives the Buttons new press handles and drops the old ones. A click carries the handle of the DOM it was made on, the CLI no longer holds it, and the press is refused (ui_press not handled). Presses are looked up by handle only: unlike ui_input and ui_select, there is no fallback by key.
2. Animated Svgs restart. Each rebuild creates a new <img>, so SMIL animation starts again from 0 every second.

Where the information is lost

1. CLI (correct). A $.state write produces

{type:"system", subtype:"ui_invalidate", event:"ui.render", instances:[{surface, component, instance_id}]}, naming only the instances that read the atom. Its schema notes that a surface ignoring instances "re-asks everything and stays correct".

1. Desktop main process, app.asar (.vite/build/index2.chunk-*.js). The message is reduced to the session id:

``js
function fs(e,t){return e.type==="system"&&"subtype"in e&&e.subtype==="ui_invalidate"?{type:"ui_invalidate",sessionId:t}:null}
``

1. Renderer (claude.ai bundle). On ui_invalidate it re-asks every entry of the session, with no notion of instances:

``js
function cr(e,t){let n=t+"\0";sr(e,t),Jn(e,{name:"ui_render:invalidate",key:t,seq:0});for(let[t,r]of e.entries)t.startsWith(n)&&(r.unanswered=0,ar(e,t,r))}
`
dd() then rebuilds any site whose answer object changed (if(e===s)return is an identity check). The answer is always a new object, so Qu() replaces the whole DOM tree, and Fs() makes a new <img> for each Svg`.

1. CLI press lookup. The CLI resolves ui_press by handle only (heldPress(plugin, handle)). A stale handle returns undefined → {handled:false}, and plugin ui.press hooks never run. ui_input and ui_select fall back to the element's key; ui_press does not, even though the desktop sends key.

Repro

A mod with:

• an atom tick, updated every second by $.clock.every(1000, …) and read only by a ui.render hook on SessionMode;
• an AbovePrompt hook that draws a <Button key="b" onPress={…}> and an <Svg> with a SMIL animation, and does not read tick.

Expected: the band is untouched by the tick. Its Button works and its animation runs continuously.

Actual:

• The band is rebuilt every second and the SVG animation restarts each time.
• If the band reads anything that changes per second, clicking the Button logs engine surface: ui_press not handled {"plugin":…,"handle":…,"key":"b"} and nothing happens.
• claude plugin test passes, because its press path looks the button up by key.

Suggested fixes

• Desktop main process: forward instances in the ui_invalidate message.
• Renderer: when instances is present, re-ask only those entries.
• Renderer: skip rebuilding a site whose new tree is identical to the current one.
• CLI: for ui_press, fall back to the element's key when the handle is stale, as ui_input and ui_select already do.

Related: Client never loads on desktop

Client is the documented way to keep an element alive across rebuilds. In this build every Client frame times out:

engine surface: Client frame torn down: did not load within 10s (a content security policy may have refused its runtime, or the module's top level never settled)

The frame host takes its script nonce from <meta property="csp-nonce"> and otherwise falls back to a random nonce. The claude.ai page has no such meta tag. The srcdoc frame inherits the page CSP (script-src 'nonce-…' 'strict-dynamic'), so the shell script carrying the random nonce is blocked before any plugin code loads. This affects every plugin's Clients.

Fix: serve the meta tag, or read the nonce from an existing script[nonce].