[Bug]: Cite inserts a raw t3-citation link when the message ID is over 512 characters#28075

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

1. Open a thread with an assistant message whose messageId is over 512 characters. In my case it's a Pi thread created through an MCP context handoff (thread:mcp:<uuid>:<thread-key>:3). I haven't found a way to create such an ID from scratch; see the example ID under Cause.
2. Select text in that assistant message and click Cite.
3. The composer shows the raw [Assistant quote](t3-citation://v1/…) text and no chip.

Without such a thread, the failing step can be reproduced directly: build a citation with a messageId over 512 characters, serialize it with the Cite serializer and parse it back. The parser returns null.

Expected behavior

The composer shows the quote chip with its comment field, like it does in other threads.

Actual behavior

The composer shows the serialized link as plain text, [Assistant quote](t3-citation://v1/<env>/<thread>/<message>?text=…), and there's no chip or comment field. Going by the source, sending it would leave the link raw, because quote expansion only replaces citations that parse. I haven't tested sending it.

Screenshots

These are crops of one screenshot. My own content is pixelated, and the ID part of the link is pixelated as well (its redacted structure is under Cause). I also removed an annotation arrow I had drawn. Nothing else was changed.

1. Selecting text in an assistant message shows the normal Cite button:

2. After clicking Cite, the expanded composer shows the raw [Assistant quote](t3-citation://v1/…) link as plain text, with no quote chip and no comment field:

Cause

The Cite action builds the link without checking it. The parser then rejects it because messageId is limited to 512 characters (messageId: …check(maxLength(512)) in the citation schema, alongside environmentId and threadId). The parse fails without any error, so the chip never renders.

The cited message's ID is 565 characters. Pi's native message ID stores the turn ID, which stores the thread ID, which stores the run ID. That run ID contains the handoff thread ID, so the thread ID appears twice, and each level percent-encodes the level below it again:

(<uuid> and <thread-key> are redacted. The real ID is 565 characters.)

This isn't a one-off. In my local statev2.sqlite, 375 of 6,925 assistant messages across 203 threads have a message_id longer than 512 characters (the longest is 684), and none of them can be cited. Only 24 of those threads are thread:mcp: threads, so handoffs aren't the only source.

Possible fixes (either would work):

• Raise or remove the 512 limit on messageId (and threadId) in the citation schema, keeping the overall URL limit. Alternatively, cite by a short stable key and not the full provider ID.
• Stop native message, turn and thread IDs from repeating and re-encoding the parent IDs, so they don't grow with each level.

The Cite button should also not offer a citation it can't parse. It could hide Cite or show an error, but not insert the raw link.

Same kind of bug as #7720 (a nested ID exceeding the 128-character PreviewTabId limit). Not the same as #22076 / #22148, which are about the collapsed composer below 640px. This one happens in the expanded composer at any width.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Nightly) 0.1.6-nightly.20261031.3956

Environment

Linux (Omarchy, kernel 7.2.8), Wayland, desktop AppImage. Provider: Pi (Claude Opus 5.5).

Notes

This was investigated with a coding agent (Claude) using the shipped app bundle and my local state database. Cite can't be used in about 5% of my assistant messages.

Workaround

Delete the raw link and paste the text manually as a > blockquote.