[BUG] Grep tool output_mode:"content" renders "[Omitted long matching line]" placeholder with no usable content for over-length matching lines

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When the dedicated Grep tool is called with output_mode: "content" and a matching line exceeds an internal output-rendering length threshold, the tool renders the literal placeholder string [Omitted long matching line] in place of the matched line's actual content. The placeholder is not a truncated prefix/suffix and does not include the matched substring — it carries zero usable content. The tool still correctly reports the match location and even renders the surrounding -A/-B/-C context lines; only the matching line itself is content-free.

Minimal reproduction (single 5000+ char line surrounded by blank lines):

Grep(pattern="UNIQUEMARKER", path="long-line.txt", output_mode="content", -C=1)

renders:

   3-
   4:[Omitted long matching line]
   5-

The agent knows where the match is but cannot see what matched, so it cannot construct a precise downstream Edit old_string from the Grep result and must issue a second, redundant tool call (Read with offset/limit over the same line range) to recover text the Grep tool had already located. For long-paragraph prose (Markdown/generated reports with no internal newlines, where a whole paragraph is one physical line) this recurs on every such match.

This is distinct from #56751 (the Bash tool silently dropping long-line grep matches with no marker at all). That report explicitly treats the dedicated Grep tool as the better case because it "at least labels truncation." This report is the counterpoint: the Grep tool's label is present but the content behind it is unrecoverable from the result, which is nearly as bad for the agent's ability to act on the match.

Possibly-related second manifestation (same "content mode returns no usable content" theme): in some sessions, calling Grep with output_mode: "content" plus -n and -B/-A against a small (~470-line) plain-text source file returned only a files_with_matches-style summary line (Found 1 file) with no content or context at all — as though output_mode: "content" were silently downgraded to files_with_matches. Observed twice in a row with slightly different flag combinations, no error emitted. I could not reduce this to a deterministic minimal repro, so I mention it here rather than filing separately; if maintainers judge it a distinct defect I'm happy to split it out.

What Should Happen?

Either would resolve the agent-trust problem for the primary case:

1. Render a truncated-but-real slice of an over-length matching line instead of a content-free placeholder — e.g. first N chars … [truncated, M chars total] … last N chars, or at least the window around the matched substring. The agent then has real text to build an Edit against.
2. Document the omission behavior and the length threshold in the Grep tool's schema/description so an agent can proactively reach for Read or -o (only-matching) instead of hitting a silent dead end.

For the second manifestation: output_mode: "content" should never silently fall back to files_with_matches; if content genuinely cannot be rendered, an explicit signal should say so.

Error Messages/Logs

# No error is emitted; the absence of usable content is the bug.
# Primary case, single 5026-char line at line 4 of a 5-line file:

Grep(pattern="UNIQUEMARKER", path="long-line.txt", output_mode="content", -C=1)
   3-
   4:[Omitted long matching line]
   5-

# grep -c / Read-with-offset over the same range confirm the match text exists;
# only the Grep-tool content rendering omits it.

Steps to Reproduce

1. Create a file long-line.txt whose second line is a single physical line longer than the internal rendering threshold (~5000 chars reproduces reliably; the cutoff appears to be in the low hundreds of columns) containing a unique token, e.g.:

``
line before
UNIQUEMARKER <thousands of characters with no newline> END
line after
``

1. Call the Grep tool:

``
Grep(pattern="UNIQUEMARKER", path="long-line.txt", output_mode="content", -C=1)
``

1. Observe: the match line renders as the literal [Omitted long matching line] while the blank/context lines around it render normally. No truncated content, no matched substring, no error.
2. Recovery requires a separate Read with offset/limit over the same line to see the text.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

2.1.212 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

Impact is a wasted tool round-trip per over-length match: the Grep result locates the match but the agent must re-Read the line range to obtain editable text. This is common when editing long-paragraph prose (generated diagnoses/reports/Markdown where a paragraph is one physical line). Related prior reports: #56751 (Bash-tool long-line silent drop, closed as stale), #16068 (count output_mode summary miscount).