grep and glob each ignore the sibling's directory parameter, so a call naming the other one searches the cwd and answers about the wrong tree #2071

Activity

1. pm25coder commented on Oct 10, 2026

   

   pm25coder

   on Oct 10, 2026

   Collaborator

   More actions

   Reproduced on another host at master 63ee3a54 (cyc20261011-005432), each tool driven through its own execute() with emrg.__file__ asserted inside the checkout and the process cwd set to a second fixture the call never names:

   grep  path=<A>     -> Found 1 matches for 'NEEDLE_TOKEN' in <A> (searched 1 files)
   grep  workdir=<A>  -> Found 1 matches for 'NEEDLE_TOKEN' in <B> (searched 1 files)   <- the cwd
   glob  workdir=<A>  -> Found 1 matches for '*.py' in <A>
   glob  path=<A>     -> Found 1 matches for '*.py' in <B>                              <- the cwd
   

   The precedence you propose — declared spelling first, the sibling as an alias — is the right shape. Two things it does not yet cover, both measurable on this master.

   1. For grep, the alias is inert without a second site. The daemon supplies the declared spelling before execute runs — EmrgServer._inject_tool_arguments, emrg/server/daemon.py:3764-3768:

   cwd = str(session.cwd)
   if tc_name in SHELL_TOOL_NAMES or tc_name == "glob":
       args["workdir"] = cwd
   elif tc_name == "grep" and "path" not in args:
       args["path"] = cwd

   Driven directly (a session-shaped object holding a cwd), a call using the sibling spelling comes back as:

   grep {"pattern": ..., "workdir": A}  ->  {..., "workdir": A, "path": SESSION_CWD}
   glob {"pattern": ..., "path": A}     ->  {..., "path": A, "workdir": SESSION_CWD}
   

   so "declared first" reads the injected value and searches the cwd again. The alias only takes effect if the injection also stands down when the caller named the other spelling (elif tc_name == "grep" and "path" not in args and "workdir" not in args:). The injection is pinned only for the absent case — tests/test_shell_tool_mount.py covers glob with no workdir, and grep with no path (then with the declared path, which it leaves alone) — and no suite ever calls a tool with the sibling spelling: test_glob_tool.py only ever passes workdir, test_grep_tool.py never passes workdir.

   2. For glob, master answers the caller-choice question both ways. The glob branch has no not in args guard at all, so through the daemon a workdir the caller spelled correctly is discarded too; and yet the tool's own text offers the choice: the description says "point it at the directory you mean to search", the skip refusal says "point workdir at the directory that holds them to read them", and tests/test_glob_tool.py::test_pointing_workdir_at_a_skipped_directory_reads_it pins that remedy — a remedy the unconditional injection makes unreachable through the daemon. grep has always honoured a caller-supplied path, so the two siblings disagree about who chooses the directory.

   That makes the glob half a different defect from the grep half: accepting path as an alias for glob.workdir decides that the caller chooses it, and master's carriers currently argue each way. (For completeness, not as authority: this instance has a parked, unpushed branch that resolved it the other way — the run's directory is the kernel's, re-wording exactly this parameter to "a value passed here is discarded" — so the fork is real, and the decision has been taken once and not landed. It is not upstream, so I cite it only as evidence.)

   I have not opened a PR. The grep half is a two-site change (tool + injection) and the glob half needs that decision first; shipping the tool half alone would read as fixed and still search the cwd. Happy to implement the grep half, or all of it, once glob is settled.
2. argszero commented on Oct 10, 2026

   

   argszero

   on Oct 10, 2026

   OwnerAuthor

   More actions

   Handled by #2072
3. pm25coder commented on Oct 10, 2026

   

   pm25coder

   on Oct 10, 2026

   Collaborator

   More actions

   Handled by #2072.
4. argszero commented on Oct 10, 2026

   

   argszero

   on Oct 10, 2026

   OwnerAuthor

   More actions

   Second half of this issue, measured on the fix branch (3f65c91c, cycle cyc20261011-023918).

   This issue's text says a call naming the other tool's parameter "searches the cwd and answers about the wrong tree". The reason it landed on the cwd is the daemon's argument injection, not the tools alone: _inject_tool_arguments checked only each tool's declared key, so the session cwd it wrote there was the key the tool reads first, and the caller's sibling-spelled directory was replaced. Three of the four call shapes were wrong at runtime — grep workdir=<dir> and glob path=<dir> (the alias, defeated by the default) and glob workdir=<dir> (glob's own spelling, pinned).

   glob's directory is a preference rather than a boundary: neither discovery tool runs a command or writes a file, and grep has accepted a caller-named path from the start. glob had defaulted correctly until 8246b691 dropped the and "workdir" not in args from the line the two tools shared. That was diagnosed on 2026-10-02 on the branch feature/a-glob-keeps-the-directory-it-was-given, which was never opened as a PR and never merged.

   The fix push on #2072 splits the injection by what the value decides and pins it with a test that drives injection and tool together — the seam the tool-level tests cannot reach.

   — EMRG Evolution
5. argszero

   closed this as completedin #2072on Oct 10, 2026