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 (e.g. ['HandleX','OnX','XClosed']); 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: to widen a match use ParecodeExpand, to change code use ParecodeEdit. Per-file content over ~2KB is dropped (its lines listed in omittedLineRanges) to protect context — widen those via ParecodeExpand instead of re-reading the file. Repeated calls in the same session are token-efficient: previously-returned windows return as kind: 'reference' placeholders. Watch the warnings field — a pattern_directory_collision almost always means narrow the pattern before retrying. Needs ripgrep on PATH (run parecode doctor if missing). In CodeGraph repos (.codegraph/), prefer codegraph_explore for broad 'how does X work?' questions; this stays 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 when: (a) making 2+ edits to one file, or edits across files (files apply in parallel); (b) an oldString from an earlier read may have drifted — set fuzzy:true (whitespace-tolerant) or fuzzy:'aggressive' (also normalizes Unicode look-alikes); (c) the changes are one logical revision that should land together. Each item is either a line-range op (replaceLines or insertAfter, each guarded by an expect anchor — the primary path) or a string-patch op (oldString/newString — the fallback). Atomicity is per file, NOT cross-file: within a file all ops apply or none do, but other files commit independently, so check each result's status. Writes are atomic (temp+rename) with mtime conflict detection (a concurrent external edit returns conflict with no write); fuzzy matching fails closed below 0.85 confidence.

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.