[FEATURE] Make Read tool file size limit configurable (Desktop app caps at 10k tokens, CLI at 25k)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The built-in Read tool has a hardcoded file size limit that differs between the Desktop app and the CLI, and cannot be configured by the user.

Current behaviour:

• Desktop app (v1.1.9310, 2026-03-27): limit is 10,000 tokens
• CLI (latest): limit is 25,000 tokens

When reading any file that exceeds the Desktop app's limit, Claude receives this error instead of the file content:

File content (125085 tokens) exceeds maximum allowed tokens (10000).
Use offset and limit parameters to read specific portions of the file,
or search for specific content instead of reading the whole file.

This blocks common real-world tasks: reading large XML files (e.g., draw.io diagrams), DOCX unpacked XML, generated JSON schemas, or any codebase file in a data-heavy format. The workaround (reading via Bash + Python) works but adds unnecessary friction and defeats the purpose of having a built-in Read tool.

Additionally, both limits (10k and 25k) feel conservative given that current models support 200k–1M token context windows. There is no mechanism to raise the limit even if the user has headroom in their context.

Proposed Solution

Two complementary improvements:

1. Align Desktop app and CLI limits — the Desktop app should use the same limit as the CLI (currently 25k). Users should not get different behaviour depending on which surface they use.

2. Make the limit configurable via settings.json — add an optional key, for example:

{
  "readToolMaxTokens": 50000
}

This would let users opt in to larger reads when their model's context window has room. The default could remain at the current CLI value (25k) for backward compatibility.

Ideally the default could also be model-aware — e.g., automatically scale to min(50000, contextWindow * 0.25) — but even a static user-configurable value would solve the problem.

Alternative Solutions

Currently working around the limit by piping large files through Bash + python or pandoc before reading:

python3 -X utf8 -c "
import sys, re, base64, zlib, urllib.parse
# ... decompress / extract text from file ...
print(extracted_text)
"

This works but:

• Requires writing boilerplate extraction code every time
• Is error-prone (encoding issues on Windows, compression variants)
• Defeats the purpose of having a native Read tool
• Is not obvious to new users who don't know the limit exists

Also tried MAX_MCP_OUTPUT_TOKENS env var in settings.json — this controls MCP tool output only and has no effect on the built-in Read tool.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Example scenario — reading a draw.io architecture diagram:

1. I ask Claude to read and analyse architecture.drawio (~144 KB, ~125k tokens as XML)
2. Claude calls the Read tool on the file
3. Desktop app returns: File content (125085 tokens) exceeds maximum allowed tokens (10000)
4. Claude cannot read the file directly; must instead write a Python decompression script, run it via Bash, and parse the output — adding 3–5 extra tool calls for a task that should take one

With a configurable limit set to 50000 in settings.json:

• Step 3 would still fail (file is 125k), but Claude could use offset/limit to read it in two chunks — a reasonable, predictable workflow
• For files under the configured limit, the Read tool would just work, as expected

Additional Context

Environment:
| Field | Value |
|---|---|
| Desktop app version | 1.1.9310 (cb30ac) |
| Build date | 2026-03-27T17:11:42.000Z |
| OS | Windows 11 |
| Auto-updates channel | latest (so this is the most recent Desktop build) |

Related issue: #14888 — Read tool limit should be dynamic based on model context window

Note on MAX_MCP_OUTPUT_TOKENS: Setting this to 50000 in settings.json does not affect the Read tool — it only applies to MCP server tool outputs. The distinction is not documented clearly, which causes additional confusion.