Best possible solution:

Land this narrow formatter and CLI bridge fix after maintainer review, and track any broader cross-provider cursor iteration separately if maintainers still want it.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main exposes --limit for message read, pins, and search, while renderMessageList still slices rendered rows to 25 and messageCommand does not forward the caller limit.

Is this the best way to solve the issue?

Yes for the central bug. The shared formatter plus CLI bridge is the narrowest maintainable boundary for the display cap, while broader provider cursor UX can remain separate.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 9238d9aeae8d.

Label justifications:

• P2: This is a normal-priority CLI/message rendering bugfix with limited blast radius and focused coverage.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes copied after-fix live Matrix CLI output showing the new pagination hint; row-limit behavior is covered by focused formatter tests.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied after-fix live Matrix CLI output showing the new pagination hint; row-limit behavior is covered by focused formatter tests.

PR surface:

Source +66, Tests +191. Total +257 across 3 files.

What I checked:

• Repository policy read: Root AGENTS.md was read fully and its read-beyond-diff, command-surface, proof, and changelog review guidance affected this review; no scoped command-path AGENTS.md or maintainer notes were present. (AGENTS.md:1, 9238d9aeae8d)
• Current main formatter cap: Current main still renders message rows from messages.slice(0, 25), so text output cannot display more than 25 returned messages, pins, or search rows. (src/commands/message-format.ts:90, 9238d9aeae8d)
• Current main bridge gap: Current main calls formatMessageCliText(result) without forwarding opts.limit, leaving the renderer unable to honor the already parsed CLI limit. (src/commands/message.ts:135, 9238d9aeae8d)
• Affected CLI options exist: The read, pins, and search command registrations expose --limit, which makes the hardcoded formatter cap user-visible when the requested limit exceeds 25. (src/cli/program/message/register.read-edit-delete.ts:16, 9238d9aeae8d)
• Latest release still has bug: Tag v2026.6.11 still contains the hardcoded 25-row cap and no formatter limit forwarding, so the behavior is not shipped-fixed. (src/commands/message-format.ts:90, e085fa1a3ffd)
• PR head threads display limit: PR head replaces the literal cap with opts.displayLimit ?? 25, preserving the default while allowing text rendering to use caller-provided limits. (src/commands/message-format.ts:92, 3364c11fd616)

Likely related people:

• steipete: git log -S 'messages.slice(0, 25)' points to the unified message tool and CLI refactor authored as Peter Steinberger, and the canonical issue also has prior review context from this account. (role: introduced formatter behavior and prior reviewer; confidence: high; commits: 3636a2bf51d9; files: src/commands/message-format.ts, src/commands/message.ts)
• vincentkoc: Recent release/current-main commits carry the existing formatter cap into v2026.6.11 and current main, making this useful shipped-behavior routing context. (role: recent release/current area carrier; confidence: medium; commits: e085fa1a3ffd, 74e7b8d47b18; files: src/commands/message-format.ts, src/commands/message.ts)
• sudie-codes: The linked issue mentions Teams pagination, and MSTeams message-action history includes the read, pin, unpin, and list-pins provider paths relevant to the broader pagination context. (role: adjacent MSTeams message action contributor; confidence: medium; commits: 0f192710924f, 355794c24a39; files: extensions/msteams/src/graph-messages.ts, extensions/msteams/src/channel.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.