Search the codebase with ripgrep and get matches plus surrounding context in ONE call — use instead of Grep/Glob-then-Read, a raw rg/grep in the shell, or re-reading the same file at different line ranges. Pass pattern as an array to run several regexes in parallel for flow tracing; each match lists which patterns hit it. Overlapping or adjacent windows in a file are merged (gap ≤ contextLines), and the result carries one envelope-level estimatedTokens so you can budget before consuming. Read-only: widen a match with ParecodeExpand, change code with ParecodeEdit. Per-file content over ~2KB is dropped (lines listed in omittedLineRanges) — widen those via ParecodeExpand rather than re-reading. Repeated calls in a session are token-efficient: previously-returned windows come back as kind: 'reference' placeholders. Only need WHERE, not surrounding code? Add mode: 'locate' for hits-only results (file + line + matched line, no content windows), then ParecodeExpand what matters. Watch warnings — a pattern_directory_collision usually means narrow the pattern first. Needs ripgrep on PATH (run parecode doctor if missing). In CodeGraph repos (.codegraph/), prefer codegraph_explore for broad 'how does X work?' questions; best for targeted multi-pattern lookups.

Apply many edits across many files in one call — the edit counterpart to ParecodeSearch/ParecodeExpand. Prefer over native Edit/MultiEdit for 2+ edits to one file, edits across files (files apply in parallel), or one logical revision that should land together. Each item is a line-range op (replaceLines or insertAfter, guarded by an expect anchor) or a string-patch op (oldString/newString; fuzzy:true tolerates whitespace drift, 'aggressive' also normalizes Unicode look-alikes). Strongly prefer line-range ops when you know the target lines — e.g. the line numbers ParecodeSearch returned: a line number plus a short expect anchor skips constructing exact-match snippets, so recurring text (a repeated call) can't trigger the multiple-match errors and retries an oldString needs extra context to avoid. Reserve oldString for edits with no known lines. Atomicity is per file, NOT cross-file: within a file all ops apply or none, other files commit independently — check each result's status. Writes are atomic with mtime conflict detection; fuzzy fails closed on low confidence or ambiguity.

Read a specific line range of a file — the natural follow-up to a ParecodeSearch match or an omittedLineRanges entry it returned. Use instead of a full-file Read (or Read with offset/limit) when you already know roughly where the code lives and just need more lines around it. Give the known (file, startLine, endLine) and optionally pad with contextBefore/contextAfter; out-of-range lines are clamped silently and the returned lineRange reflects the actual slice. Reports estimatedTokens in the same form as ParecodeSearch so you can budget before consuming. Read-only — to change code use ParecodeEdit.