Best possible solution:

Land one proof-positive parser-boundary fix, preferably #99399, then close the linked issue and the duplicate open fix candidates.

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

Yes at source level: current parsePageRange("1.5", 20) follows the single-token Number(part) branch, and fallback extraction filters non-integer pages later. I did not run tests because this review was constrained to read-only inspection.

Is this the best way to solve the issue?

No for this branch as the best landing path: the parser-boundary change is plausible, but #99399 already covers the same fix with stronger real behavior proof and tool-boundary coverage.

Security review:

Security review cleared: The diff tightens PDF parser validation and adds tests; it does not touch dependencies, workflows, secrets, package metadata, or supply-chain execution paths.

AGENTS.md: found and applied where relevant.

What I checked:

• Current parser accepts fractional tokens: Current main documents 1-based page numbers but parses single page tokens with Number(part) and only rejects non-finite or values below 1, so "1.5" can enter the pageNumbers contract. (src/agents/tools/pdf-tool.helpers.ts:49, 5342effebcf7)
• PDF tool forwards parsed pages: createPdfTool computes pageNumbers once from parsePageRange and passes the value to extraction and model routing, making the helper the shared input boundary. (src/agents/tools/pdf-tool.ts:498, 5342effebcf7)
• Fallback extractor drops non-integers: The document extractor filters requested pages with Number.isInteger(p) && p >= 1 && p <= pdf.pageCount, so fractional parser output can be silently removed downstream. (extensions/document-extract/document-extractor.ts:68, 5342effebcf7)
• Documented pages contract: The public PDF docs describe pages with integer-style examples such as 1-5 and 1,3,7-9, and say it is parsed as 1-based page numbers. Public docs: docs/tools/pdf.md. (docs/tools/pdf.md:52, 5342effebcf7)
• Current PR diff: This PR adds Number.isInteger(num) to the helper and two helper-level tests, but no PDF tool-boundary test or real behavior proof is included in the PR body. (src/agents/tools/pdf-tool.helpers.ts:68, 36486b2c3753)
• Canonical sibling PR is viable: fix(pdf): reject fractional page selections #99399 is open, mergeable, has proof: sufficient, and covers the same parser boundary with helper plus createPdfTool().execute(...) fallback-boundary proof and tests. (451ef0407653)

Likely related people:

• tyler6204: Authored and merged the original PDF analysis tool PR that added parsePageRange, the public pages argument, and the main PDF tool implementation. (role: introduced behavior; confidence: high; commits: d0ac1b019517, 2c257cf97d13, 0b57ca3b5ce3; files: src/agents/tools/pdf-tool.helpers.ts, src/agents/tools/pdf-tool.ts, src/agents/tools/pdf-tool.test.ts)
• zhangguiping-xydt: Authored the recently merged empty parsed page-range fix in the same parser helper and PDF tool tests. (role: recent adjacent repair author; confidence: high; commits: a5165d6a8486, aadd57c31cc8; files: src/agents/tools/pdf-tool.helpers.ts, src/agents/tools/pdf-tool.helpers.test.ts, src/agents/tools/pdf-tool.test.ts)
• steipete: Git history shows recent PDF tool helper and test refactors around the affected parser and validation surface. (role: recent area contributor; confidence: medium; commits: 7240830ca42f, 998cc02af40c, 42ae213ba6f4; files: src/agents/tools/pdf-tool.helpers.ts, src/agents/tools/pdf-tool.helpers.test.ts, src/agents/tools/pdf-tool.test.ts)
• vincentkoc: Merged the adjacent empty-page parser fix and has recent shared PDF test setup work near this surface. (role: recent merger and adjacent contributor; confidence: medium; commits: aadd57c31cc8, b4f5c748c3da; files: src/agents/tools/pdf-tool.helpers.ts, src/agents/tools/pdf-tool.test.ts)

Codex review notes: model internal, reasoning high; reviewed against 5342effebcf7.