smashimo/oh-my-pi
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(tool): exempt piped-stdin stages from bash interceptor

Browse Source 
The 17.2.2 compound-fragment matching splits commands on every unquoted
operator including `|`, so a downstream pipe stage like `grep x` in
`printf 'x\n' | grep x` became a standalone interception candidate and was
routed to the `grep` tool, which searches paths and cannot consume the
previous stage's stdout.

`extractFlatShellCommandSegments` now flags each segment that receives piped
stdin from a single unquoted `|`, and `interceptionCandidates` skips those:
a stdin-consuming stage cannot be replaced by a path-based dedicated tool.
Standalone (`grep pattern path`), first-stage (`grep x file | wc`), and
`&&`/`||`/`;`-sequenced commands still match.

Fixes #7496
This commit is contained in:
roboomp
2026-08-03 12:36:36 +00:00
parent 5039b33a11
commit cbfbcd865e
6 changed files with 80 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/bash-tool-runtime.md
+1 -1
View File
@@ -32,7 +32,7 @@ There are no structured `head` or `tail` tool parameters in the current schema,
## 2) Optional interception (blocked-command path)
If `bashInterceptor.enabled` is true, `BashTool` loads rules from settings (`getBashInterceptorRules()`) and runs `checkBashInterception()` against the command — checking both the original and the cwd-normalized form (after a leading `cd … &&` is extracted) when they differ. Rule syntax is unchanged: each rule checks the complete input first, then raw flat command fragments separated by unquoted/unescaped `&&`, `||`, `;`, `|`, `&`, or newlines, then those fragments with leading `NAME=value` assignments removed.
If `bashInterceptor.enabled` is true, `BashTool` loads rules from settings (`getBashInterceptorRules()`) and runs `checkBashInterception()` against the command — checking both the original and the cwd-normalized form (after a leading `cd … &&` is extracted) when they differ. Rule syntax is unchanged: each rule checks the complete input first, then raw flat command fragments separated by unquoted/unescaped `&&`, `||`, `;`, `|`, `&`, or newlines, then those fragments with leading `NAME=value` assignments removed. Fragments that receive piped stdin from a single unquoted `|` are excluded from the fragment candidates, because a stdin-consuming stage cannot be replaced by a path-based dedicated tool.
Interception behavior: