Oversized PDF kills the REPL

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/9789
2. https://github.com/anthropics/claude-code/issues/6231
3. https://github.com/anthropics/claude-code/issues/8077

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This issue should be reopened as it is not a duplicate of the referenced issues.

Why This Is a Distinct Bug

This issue (#11527) and #9789 describe a specific bug where Claude Code enters an infinite error loop that makes the REPL completely unusable:

• After encountering an oversized PDF, Claude responds with "PDF too large. Please double press esc to edit your message and try again"
• Every subsequent input (regardless of content) receives the same error message
• The REPL becomes permanently stuck in this state and cannot accept any other commands
• User must kill the session to recover

Why the Referenced "Duplicates" Are Different

The issues marked as duplicates describe different symptoms:

• #6231 and #6197: PDF error persists in the conversation history and causes API errors on subsequent API calls, but the REPL still attempts to process commands
• #8077: Session crashes/terminates completely with tool_use/tool_result mismatch errors

This bug is about the REPL entering a persistent error state where it stops processing any input at all and only echoes the PDF error message.

Evidence

Issue #9789 was incorrectly auto-closed as a duplicate of #6231, and users confirmed "Still happening" after closure. The infinite loop behavior is a specific manifestation that requires its own fix - likely in the TUI/REPL error handling rather than just PDF size validation or API error handling.

Please reopen this issue so the specific infinite loop bug can be tracked and fixed.

Workaround: Prevent PDF crashes with CLAUDE.md configuration

I've been experiencing the same crash issue when Claude Code tries to read
large PDFs. Found a reliable workaround by adding mandatory instructions to
.claude/CLAUDE.md:

## PDF Processing

# NEVER use the Read tool to open PDF files directly
# ALWAYS extract PDFs to text first using pdftotext via Bash before
processing
# Reading large PDFs can cause crashes and loss of work

The # prefix makes these instructions high-priority and enforceable.

Workflow that works:

1. Use pdftotext via Bash to extract PDF to .txt file first
2. Process the text file instead of the PDF
3. Keep extracted .txt files alongside PDFs for future reference

This completely avoids the crash issue and is actually faster since text
files are easier to search/process. Would be great if this could be built
into Claude Code as a default behavior or at least a warning before
attempting to read large PDFs.

I have this exact same problem in:
Claude Code v2.0.42
Sonnet 4.5 · Claude Pro

Here is a transcript:

I don't have access to previous sessions, so I can't see what happened, but I can address both issues: File Size Restrictions Looking at the Read tool description available to me, I don't see explicit size limits documented for PDFs. The description says PDFs are "processed page by page, extracting both text and visual content," but doesn't specify a maximum file size. A 5MB PDF hitting a size limit suggests there is one, but I don't have that specific information in my current documentation. Why I Got Stuck The behavior you described—repeatedly giving the same "PDF too large" response to all follow-on questions regardless of context—is definitely a bug/error state. That shouldn't happen. Once I encounter an error with one request, I should still be able to: - Answer different questions - Respond to context changes - Understand when you're asking about something else entirely Getting stuck in a loop repeating the same error message is not correct behavior. What You Can Do Since this is a technical limitation question about Claude Code itself, you could: 1. Check the Claude Code documentation at https://code.claude.com/docs/ 2. Report this as an issue at https://github.com/anthropics/claude-code/issues (especially the "stuck in loop" behavior) Is there something else I can help you with regarding the documentation or the project? (And I'll wait for your explicit instruction before attempting to read that PDF!) > Can you try to look at the PDF file again? When compared to the HTML documentatoin, it looks terrible and isn't even close... ● Read(docs\build\latex\eips-tools.pdf) ⎿  Read PDF (513.6KB) ● PDF too large. Please double press esc to edit your message and try again. > Are you stuck again? ● PDF too large. Please double press esc to edit your message and try again. > version ● PDF too large. Please double press esc to edit your message and try again. > /exit

⏺ PDF too large. Please double press esc to edit your message and try again.

Impacts 2.0.55. A workaround is that you can use /rewind to restore to the message before the read.

It is a hang at the pure repl level, the json SDK seems to continue to function. I suspect a hung bit of state in the outer typescript.

Happening to me also in v2.0.59 :/

I have this exact same issue, but I can't rewind it because I referenced a PDF in a question Claude asked me. If I rewind, I'll need to redo the whole plan Claude created for me. This is very annoying and it would be nice if it could be fixed.

see the screenshots below

<img width="1568" height="102" alt="Image" src="https://github.com/user-attachments/assets/362b28cf-f94b-44a0-8c6d-ad21e70ad082" />
<img width="1109" height="562" alt="Image" src="https://github.com/user-attachments/assets/80f73755-7a8c-4b78-bf89-154ce53bb6b2" />

Version: 2.0.65

Happening to me as well in v 2.0.76 :( And I just learned there is no rewind command in CC via VS Code IDE, so no way to go back, I have to create a new conversation

When working with complex PDF tables—especially engineering specifications, multi-column data sheets, or documents with merged cells and nested headers—Claude Code struggles significantly with traditional text extraction methods.

Why text extraction fails on complex tables:

• pdftotext and similar tools flatten table structure
• Column alignment is lost when cells span multiple lines
• Merged cells become fragmented text
• Headers get mixed with data rows
• Unicode characters and special symbols corrupt parsing

I was spending hours manually copying data or wrestling with Power Query's "Get Data from PDF" feature, which required:

• Manual column delimiter adjustments
• Row-by-row error correction
• Repeated imports for multi-page tables
• Custom M code for edge cases

The Solution: WebP Image Conversion

Instead of fighting with text extraction, convert PDF pages to WebP images and let Claude Code's vision capabilities read the table directly.

The Workflow

# Convert PDF page(s) to WebP images
pdftoppm -webp -r 150 "specs.pdf" "output"

# Results in: output-1.webp, output-2.webp, etc.

Then simply ask Claude Code to read the image:

Read output-1.webp and extract the table data to CSV format

Why This Works

Claude Code's multimodal capabilities can:

• See the actual visual table structure
• Understand merged cells and spanning headers
• Preserve column relationships
• Handle complex nested layouts
• Process special characters and symbols correctly

This works approximately 100x faster than Power Query for complex tables.

Best Practices

Image Quality Settings

# 150 DPI is usually sufficient for tables
pdftoppm -webp -r 150 input.pdf output

# For dense/small text, use 200-300 DPI
pdftoppm -webp -r 200 input.pdf output

Why WebP over PNG/JPEG?

• Smaller file size than PNG (faster upload/processing)
• Better quality than JPEG (no compression artifacts on text)
• Claude Code handles WebP natively

For Multi-Page Tables

# Convert specific pages only
pdftoppm -webp -r 150 -f 3 -l 5 input.pdf output # Pages 3-5

# Then process sequentially

Prompting Tips

Good prompt:
Read this image and extract the table to CSV format.
The table has headers: Part Number, Size, Dimension A, Dimension B, and Weight.
Use commas as delimiters and preserve empty cells.

Better prompt (for complex tables):
Extract all table data from this engineering specification sheet.

• Maintain the relationship between size designations and their corresponding dimensions
• Convert fractions to decimals
• Include units in a separate column if present
• Output as CSV with headers from the first row

Limitations

• Very large tables (100+ rows) may need to be split across multiple images
• Handwritten annotations won't parse well
• Severely degraded/scanned PDFs may need OCR preprocessing first
• Claude Code context limits apply to extracted data

Tools Required

# Install poppler-utils for pdftoppm
sudo apt install poppler-utils

# Verify installation
pdftoppm -v

Conclusion

If you're spending significant time extracting table data from PDFs using Power Query, Python libraries like tabula-py, or manual copy-paste, try the WebP conversion method with Claude Code. For complex tables with irregular structures, it's not just faster—it's more accurate.

The key insight: treat table extraction as a vision problem, not a text parsing problem.

Tested with Claude Code on engineering specification sheets, mfg list price sheets, and it works every time where Claude struggled before.

Ultra plan user here. Happens to me almost everyday... it's a nightmare :(

I can confirm that I ran into this issue today (Jan 2, 2026) while using claude to read PDF files. Same infinite loop, even if restarting with claude --continue.

Cam back to check on this. This workaround still works:
https://github.com/anthropics/claude-code/issues/11527#issuecomment-3599387617

Cam back to check on this. This workaround still works: #11527 (comment)

Can you explain what this means? How does that help in practice? Sorry, might be obvious ...

Happening to me right now on v2.1.42. How do I get out of this loop?

This is hardly stale just because Anthropic people haven't commented they are working on it.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.