grep/read: line preview starts at column 0, hiding the match it just reported

[phoenix13023]

Labels: bug tools agent-reliability

Summary

grep reports Found N match and then renders at most GREP_MAX_LINE_BYTES = 2000
(packages/fs/tool-fs-search/src/grep.ts:36) of the matched line, starting from the
beginning of the line (previewLine, search-core.ts:318-324), ending with
(line truncated). For a minified JSON file — which is one line — the match can be
past the window, so the tool simultaneously asserts the text exists and shows none of it.
read has the same shape: READ_MAX_LINE_LENGTH = 2000
(packages/fs/tool-fs/src/read-render.ts:11), marker ... (line truncated to 2000 chars).

read's offset/limit count lines, so paging cannot reach the match either: for a
one-line file, any offset yields the same truncated first line.

Consequence observed in production

In a recorded runaway session the agent ran grep '"glm-5' against an 8208-byte single-line
provider catalog whose first match sat at offset 2393 — 393 bytes past the window. The
tool said Found 1 match; the agent wrote "确认 catalog 里根本没有 glm-5.x", then built an
elaborate (false) theory that the settings validator never runs, and told the user their
working configuration "可能根本没真正工作过". The correct fix was already in its hands one
step earlier. That is a 17-step detour caused by output formatting.

Suggested fix

1. Show the match location, not the line head: start the preview window at/near the
   match column, or print offset=<n> alongside the truncation marker so the reader knows
   bytes were skipped before the match.
2. Consider a --around-match window of k bytes centred on the match.
3. Cheap documentation win: state in the tool description that the line preview is capped
   and that a match may be outside the visible window, so Found N match is itself
   evidence of presence.

Reproduction

printf '{"a":1,...pad to 2400 bytes...,"glm-5.1":{}}' > one-line.json   # one line, no \n
grep '"glm-5' one-line.json

Actual: Found 1 match + first 2000 bytes + (line truncated); "glm-5.1" not shown.

---

[173787247]

会话 / 历史（「grep/read: line preview starts at column 0, hiding the match it just reported」）

会话数据一般在用户目录下的 dsh 数据路径（随版本可能是 ~/.dsh 或文档写明的 data dir）。重装前应先备份整个数据目录再覆盖。

1. 找到旧版本数据目录（含 session / trajectory 文件）
2. 完整退出 dsh
3. 复原到新版本对应目录后启动
4. 大版本跨越可能不兼容——看 Release note 是否有 migration

不要只拷单个 .jsonl 而漏掉索引/侧车文件（有的版本还有 .zstd 等）。

[PerryLink]

Confirmed on master (c291e79). Both tools still cut the preview from column 0, so a match past the window is
simultaneously asserted and invisible:

• grep: cap is GREP_MAX_LINE_BYTES = 2000 (packages/fs/tool-fs-search/src/grep.ts:35); the preview is built from the
  start of the line (packages/fs/tool-fs-search/src/search-core.ts:321-326) and suffixed (line truncated).
• read: READ_MAX_LINE_LENGTH = 2000 (packages/fs/tool-fs/src/read-render.ts:11), line.substring(0, maxLineLength)
  at read-render.ts:70. read pages by line number, so a one-line file can never page past the head.

Your incident (17-step false theory from Found 1 match with the match invisible) is exactly the failure mode — the
tool's own output contradicts itself.

Workarounds for the model today: for single-line/minified files, have the agent extract the region with the shell
instead of the line-based tools — e.g. pwsh: $t = Get-Content -Raw path; $t.Substring(2300, 500) or
rg -o '"glm-5[^"]*"' path (regex-only output shows the match itself, not the line head). A cheap doc win worth
landing upstream: state in the tool descriptions that the preview is capped and a match may fall outside the visible
window. The real fix is your suggestion — window the preview around the match (or print offset=<n>), so the tool
never reports a match it then hides.

[reneleonhardt]

Thank you for your detailed report!
Why is it forbidden to report issues and contribute PRs?

[PerryLink]

Thanks! To be precise, reporting issues isn't forbidden — it's explicitly
encouraged: CONTRIBUTING.md asks you to report bugs in GitHub Discussions and
upvote the ones that matter ("we monitor them and consider them when
allocating resources"). What the project can't accept at the moment is
external pull requests ("we cannot accept external pull requests at the
moment") — an early-stage policy, not a ban on reports.

So please keep reporting. The small doc win I suggested above (tool
descriptions stating the preview is capped and a match may fall outside the
visible window) is exactly the kind of thing that can be posted or upvoted as
a discussion — that's how things get onto the team's list here.