The grep/glob multipath detector probed the raw joined string with lstat
and only split when the probe reported "missing" (ENOENT/ENOTDIR).
ENAMETOOLONG was classified as "unknown", which suppressed the split, so
a semicolon-delimited path list long enough to exceed NAME_MAX or
PATH_MAX collapsed to one literal path and failed with
"Path not found: <whole list>" even though every entry existed.
Classify ENAMETOOLONG as "missing" in probeLiteralPathExists and
delimitedPathPartResolves (a too-long string can never name a real
single entry), and broaden glob's stat catch so the raw errno never
reaches the caller.
Fixes#7597
expandPath's leading-colon strip only fired before POSIX prefixes
(`/`, `~/`, `./`, `../`), so Windows-mangled inputs like `:C:\repo\file`
or `:.\src` slipped through and path.resolve treated them as relative
children of cwd. The omp grep subcommand is the Windows grep path, so it
hit the common Windows form of the same bug.
Broaden the lookahead to admit `\` separators, `.\`/`..\` relatives, and
drive-letter absolutes (`[A-Za-z]:`). Add expandPath regression tests
for the Windows forms and the bare-token non-strip cases.
Fixes#5624
The `omp grep` subcommand resolved its path argument with a bare
`path.resolve` in `runGrepCommand`, bypassing `expandPath`. The
leading-colon strip from #5529 never fired, so `:/abs/path` was
mangled into `<cwd>/:/abs/path` and failed to resolve.
Route the path arg through `expandPath` so it inherits the leading-`:`
strip plus `@`-prefix, tilde, and unicode-space normalizations, matching
`read`/`edit`/in-agent `grep`.
Fixes#5624
- Removed `selector`/`sel` arguments from read and grep tool schemas and related execution arg handling.
- Reworked read and grep path processing to parse line selectors from `path` suffixes instead of separate fields, including inline range propagation.
- Updated delegation and execution call paths (including JS/Python preludes and executor tests) to pass selectors embedded in `path`.
- Updated read/grep prompt docs and changelog for the breaking inline-selector API, and removed obsolete selector-specific tests and expectations.
Some models intermittently prefix an otherwise-valid path with a leading
`:` (e.g. `:/abs/path`, `:../rel`). read/edit/grep hard-failed because
resolveToCwd left the colon intact and resolution missed the real file.
The #4618 literal-preferring probe cannot recover it: the literal
`:/abs/path` does not exist on disk, so the peel proceeds to an empty
path.
Strip the mangled prefix in expandPath — the shared resolution funnel for
read (resolveReadPath), grep (resolveToolSearchScope), and edit
(resolvePlanPath) — mirroring the existing @-prefix normalization. The
lookahead only fires before `/`, `~/`, `./`, or `../`, so selector-shaped
tokens like `:raw` are untouched.
Fixes#5508
Two Codex bot findings from earlier PR reviews were still open.
1. local:// URL selector shadow (read.ts): the local:// branch resolved
`local://foo:1-2` and rewrote readPath to `${localFile.path}:${sel}`,
then let splitPathAndSelPreferringLiteral run on the synthesized
string. A sibling literal `${localFile.path}:${sel}` file would win
over the intended URL selector semantics. The branch now promotes the
URL selector into the explicit-selector state and sets
readPath = localFile.path, so downstream literal-preferring routing
never re-splits the concatenation.
2. Delimited expansion before literal probe (path-utils.ts): grep called
expandDelimitedPathEntries before parsePathSpecs, and
splitDelimitedPathEntry only checked whether the peeled base of the
entry resolved. A real POSIX file whose name contained a delimiter
plus a selector-shaped tail (a;b:1-2) got split into ["a", "b:1-2"]
and never reached the literal-preferring probe. splitDelimitedPathEntry
now short-circuits on probeLiteralPathExists — "missing" is the only
outcome that lets delimiter expansion run.
Added regressions: `read local://notes.md:1-2` still slices the base file
when a sibling `notes.md:1-2` literal exists, and grep searches a real
`a;b:1-2` file without semicolon-splitting.
resolveExistingReadPath treated any stat failure other than ENOENT/ENOTDIR as
"exists" and any other resolved path was considered a hit. That silently
reinterpreted a real literal path such as test:1-2 as test plus selector 1-2
whenever the raw path was a dangling symlink, sat under an unreadable parent,
or hit a transient I/O error.
The new probeLiteralPathExists returns "exists" / "missing" / "unknown" from
an lstat probe. splitPathAndSelPreferringLiteral now falls back to the strict
selector split only on "missing"; both "exists" and "unknown" keep the raw
path, so an unreachable literal is never reinterpreted. Grep and read use
the same probe: the explicit selector branch keeps the literal path when
existence is uncertain, and only a definitive ENOENT/ENOTDIR lets structured
archive/sqlite/pdf dispatch take over.
Added regressions covering probeLiteralPathExists exists/missing/dangling-
symlink cases and splitPathAndSelPreferringLiteral over a dangling symlink.
The literal-path stat fallback made selector-shaped filenames accessible, but it did not give callers a deterministic way to read or grep a range from a literal filename such as test:1-2. Encoding that as test:1-2:1-2 remained recursively ambiguous if a longer literal file later appeared.
Read now accepts an optional selector field that is parsed independently from path. When selector is present, path is treated as the exact path first, so { path: "test:1-2", selector: "1-2" } always means lines 1-2 from the literal file test:1-2. Inline :<sel> remains supported for compatibility.
Grep now accepts an optional line-range selector field with the same literal-path behavior. Explicit selectors bypass path suffix peeling, while archive/internal/URL routing still handles non-literal structured paths.
Updated read/grep tool prompts and added deterministic regressions proving that a longer literal file like test:1-2:5-6 or test:1-2:2-2 does not change the meaning of { path: "test:1-2", selector: ... }.
splitPathAndSelPreferringLiteral only statted resolveToCwd(rawPath), so shell-escaped paths such as dir/a\ b:1-2 missed the existing dir/a b:1-2 file and fell back to the strict selector peel. That let read target dir/a\ b with a range instead of the literal filename.
The helper now probes resolveReadPath(rawPath, cwd), reusing the read path resolver's existing escaped-space and filesystem variant normalization before deciding whether the literal file exists.
Grep also stores the resolved filesystem path for literal matches so the later search-scope parser does not reinterpret backslashes as path separators. Regression coverage now includes helper, read, and grep cases for dir/a\ b:1-2.
parsePathSpecs preserved an existing literal path like data.zip:1-2, but resolveArchiveSearchPaths only received the cleaned path strings and reparsed the same literal as archive data.zip plus member 1-2. If data.zip existed, grep materialized or errored on the archive member before searching the literal file.
GrepPathSpec now carries whether a local entry was kept because the raw filesystem path exists. Archive materialization consumes the specs instead of bare strings and skips those literal matches, while ordinary archive selectors still materialize as before.
Regression coverage adds grep over data.zip:1-2 with a real data.zip alongside, proving the literal file is searched instead of the archive member.
The prior hunk placed the literal-preferring split after resolveArchiveReadPath,
resolveSqliteReadPath, and splitPdfImageMemberReadPath, so a real POSIX file
such as data.zip:1-2 or notes.db:1-2 still got hijacked: the archive/sqlite
resolvers matched the base extension, opened data.zip / notes.db, and errored
on the phantom :1-2 member before the literal file was ever considered.
Now the async splitter runs first. When the strict grammar would have peeled
a suffix but the literal path stats successfully, all three structured
dispatchers decline. Otherwise the ordering is unchanged, so archive/sqlite/
pdf-image reads keep working when the literal file does not exist.
Regression coverage adds `data.zip:1-2` and `notes.db:1-2` cases where the
base archive/sqlite file also exists on disk, exercising the exact ordering
bug the reviewer flagged.
splitPathAndSel unconditionally peels a trailing :<sel> chunk whenever it
matches the read-tool selector grammar (raw, conflicts, N-M, N+K, ...). On
POSIX, filenames may legitimately contain colons, so a real file named
test:1-2 or log:raw was shredded to test/log before either read.ts or
grep.parsePathSpecs stated anything and both surfaced "Path not found".
Added splitPathAndSelPreferringLiteral(rawPath, cwd) alongside the strict
splitter: it only overrides the peel when fs.stat succeeds against the raw
path. Read (execute) and grep (parsePathSpecs) call the async variant for
non-URL paths; internal-URL splitting stays unchanged. Regression covers
splitter fallbacks, read/grep behavior on literal-colon files, and that
:1-2 selectors still work when the base file is the only real match.
Fixes#4618
roboomp