fix(parser): require structured queued-picker evidence

[EtanHey]

Summary

• prevent ordinary Claude checklist/numbered transcript above a queued-message composer from being misclassified as an open picker
• keep blocking a genuine AskUserQuestion picker that renders the same queued-message footer by requiring stronger structural evidence

Context

PR #311 merged externally at 579c814 while its final Codex review was still surfacing this false-positive case. This follow-up contains only the reviewed fix commit 8fb0abc; the branch diff against current main is two files, 42 additions and 5 deletions.

Test plan

• RED regression: ordinary checklist/numbered transcript plus Press up to edit queued messages returns false
• positive regression: structured AskUserQuestion picker with that footer returns true
• bunx vitest run --silent — 98 files, 1,829 tests passed
• bun run pre-pr — typecheck plus 61 harness tests passed
• bun run build
• bun run typecheck
• git diff --check
• push hook run_tests.sh — 98 files, 1,829 tests passed

Review provenance

Fixes the final Codex review thread from #311: #311 (comment)

---

Note

Low Risk
Localized heuristic change in screen-parser picker detection with targeted regressions; misclassification could still affect automation that gates on interactive_overlay.

Overview
Tightens Claude picker detection when the navigation footer is "Press up to edit queued messages", so normal transcript (checklist headers, numbered bullets, composer line) above that footer is no longer treated as an active menu.

hasPickerNavigationBlock no longer treats any single Claude picker chrome line as sufficient. It now requires structured evidence: a checkbox-style header and a cursor-selected numbered option (PICKER_SELECTED_NUMBERED_OPTION_RE), or at least two aux lines like "Type something" / "Chat about this". Real AskUserQuestion pickers that share the same queued-message footer still classify as pickers.

Tests add a regression for checklist + numbered transcript + queued footer → not a picker, and a positive case for a structured picker with that footer → is a picker.

^{Reviewed by Cursor Bugbot for commit 8fb0abc. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix hasPickerNavigationBlock to require structured picker evidence when a queued-message footer is present

• Ordinary checklists followed by Claude's queued-message footer were being misclassified as active pickers; this PR tightens the detection logic in screen-parser.ts.
• Introduces PICKER_SELECTED_NUMBERED_OPTION_RE to match currently-selected numbered options (lines beginning with >, ❯, or ›).
• A "structured Claude picker" now requires either a Claude picker header plus a selected numbered option, or at least two auxiliary options. The queued-message footer path requires this stricter check.
• Adds two tests covering the regression case (checklist + queued footer → not a picker) and the valid case (structured picker + queued footer → still recognized).

^{Macroscope summarized 8fb0abc.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_dd02da75-62c1-44fb-9bdc-dba885c33fbc)

[coderabbitai]

Warning

Review limit reached

@EtanHey, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 42 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: e48f4fc3-de5c-46a7-be4f-57d9f0396647

📥 Commits

Reviewing files that changed from the base of the PR and between 7761d63 and 8fb0abc.

📒 Files selected for processing (2)

• src/screen-parser.ts
• tests/screen-parser.test.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/picker-blocked-delivery

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[EtanHey]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8fb0abc7bc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Handle glyph-selected queued options

The option matcher just above accepts glyph-only numbered choices such as ◉ 1. ... or ☑ 1. ..., but this new selected-option regex only reports a selection when an arrow also precedes the glyph. For a queued-message Claude picker rendered with a header plus glyph-selected choices and fewer than two auxiliary choices, hasStructuredClaudePicker stays false, so the delivery guard treats the open picker as safe and may type into it.

Useful? React with 👍 / 👎.