Follow Discord
Sweep 10 Nov 2026 · 02:18Z Build v2.1.322 539 read Stable v2.1.311 Latest v2.1.322 Next v2.1.322 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.277 ·

Plugin UI rendering adds an Image element alongside Raster

Plugin UI components can now draw and target an Image element, not just the existing Raster/cell-based canvas

Group of 4 Under the hood Internal Changes
JSON All of v2.1.277
Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
Plugin UIArea: what it touches
Internal ChangesKind: in v2.1.277,
Internal ChangesSection of the release

What

  • The rendering diff/restamp pipeline now handles a new Image element type alongside the existing Raster, with matching stamp/seen-key/refusal logic and an error when a render hook returns an image it didn't draw.
  • The Image render-props validator now accepts an optional key prop, which must be a non-empty string when present, and for images without columns/rows or a resolvable source, it requires the image to be "stamped by a plugin of this chain," otherwise reporting Image "<key>" is not stamped by a plugin of this chain.
  • The raster/paint tool's input can now target an Image source directly, using { requestId, key, source }, in addition to the existing cell-data form { requestId, key, cells }.
  • ui.blit change detection now also treats a change in whether a source field is present or absent as meaningful, and its description now mentions "the Raster or Image being blitted" instead of just the Raster.

Why

This lets plugins draw with a full image source rather than only an encoded grid of cells, while keeping the same ownership and stamping checks that stop one plugin from tampering with another plugin's drawing.

Read from
Names in the bundleui.blit
What the documentation says

See this entry in the whole of v2.1.277 →

Feedback