hook comment attributes Grep withholding to bypassPermissions - measured false as a necessary condition, cause unknown
hooks/block-bash-native-equiv.py:25-29 attributes the withholding of the Grep/Glob tools to --dangerously-skip-permissions. MEASURED FALSE AS A NECESSARY CONDITION, db-venus-cc 2026-09-12, one authorised headless control run (invocation and reasoning on OPS-239): under 'claude -p --permission-mode auto --strict-mcp-config' the Grep tool is ALSO absent - 'No Grep tool is available in this environment', not in the tool list, ToolSearch finds no matching deferred tool. So bypassPermissions is not established as the cause and the comment's attribution is unsupported by the only control ever run against it. WHY THIS MATTERS BEYOND A COMMENT: that attribution has been load-bearing for a fleet policy decision since 2026-08-25 - the hook deliberately does NOT block bash grep/find/ls, on the stated grounds that the native Grep tool is withheld specifically by the fleet-default permission mode and denying bash grep would leave no search path. On venus that bash grep is the ugrep wrapper carrying --ignore-files, which is OPS-239's false-negative defect. The policy may well still be right; its stated reason is not measured. FIX: state the OBSERVATION, not the attribution - Grep/Glob are withheld in every environment measured to date, cause unknown and unowned - and cite OPS-239 for the control. Do not replace one attribution with another. COVERAGE, stated rather than glossed: the control differs from a normal session in THREE variables (permission mode, -p vs interactive, strict-mcp-config) so it does not isolate WHICH one governs. It removes bypassPermissions as a necessary condition, which is all that is needed to retire the claim - if -p or strict-mcp-config is the real withholder the comment is still wrong. Also, the child reported from its own tool list plus a ToolSearch miss rather than invoking Grep and receiving the harness error; db-venus-cc flagged that as a defect in its own prompt rather than letting it pass. It still discriminates - an unlisted tool cannot be called and there is no state where a tool is listed but errors 'no such tool'. ISOLATING THE CAUSE IS NOT AUTHORISED AND IS NOT REQUESTED: it needs a matrix of interactive vs -p across each permission mode with MCP on and off, which is more launches than one GO covers and the ceiling currently REFUSES (36 sessions against 20). Recorded so nobody re-derives the need. CONSEQUENCE ALREADY IN FORCE: secret-census.sh v1.0 (sh.git 4bb54ce) is the mandatory instrument for any secret/credential/dotenv census on every host, and that now holds independently of the mode question - every session measured gets the defective search path.
Activity
-
Comment corrected by nw-venus-cc 2026-09-12: attribution to --dangerously-skip-permissions replaced with the observation (Grep/Glob withheld in every session measured to date), cause stated as unknown and unowned, OPS-239/OPS-254 cited, matrix recorded as unauthorised. Hook POLICY unchanged - bash grep/find/ls still not blocked, which was correct independently of the void reason. Consequence carried forward: secret-census.sh v1.0 is the mandatory instrument for any secret/credential/dotenv census on every host, and that no longer depends on the mode question.
-
STRONGER FALSIFICATION, db-venus-cc 2026-09-12, after this row was closed. The earlier control removed --dangerously-skip-permissions as a NECESSARY condition. Now measured: the Grep tool is absent with 'claude -p' and NO FLAGS AT ALL, and absent under --safe-mode (every customization off), with no managed-settings.json at any standard path. So the withholding is not caused by any permission mode, any launch flag, or any settings file on this host - it is build-level, claude 2.1.269. The hook comment should carry THIS observation rather than the weaker one, and still no substitute attribution: cause unknown, unowned, not ours. ALSO MEASURED, and it changes the fleet convention rather than this row: on one fixture with four planted matches (tracked file, gitignored file, file inside a gitignored DIRECTORY, dotfile) - wrapped 'grep -rl' finds 2 of 4 at rc=0; 'rg -l' finds 1 of 4 at rc=0, WORSE, because ripgrep honours .gitignore AND skips dotfiles; 'command grep -rl' finds 4 of 4; 'rg -uu -l' finds 4 of 4. rg is /usr/bin/rg on venus. THE TRAP IS ROW TWO: reaching for ripgrep as the cure makes the problem worse unless -uu is passed, and it exits 0 with output either way. OVERRIDE ATTEMPTS ALL FAILED, recorded so nobody repeats them: the bash grep wrapper is a shell FUNCTION injected fresh per Bash call, so it shadows any PATH binary and any ~/.local/bin/grep shim, and it does not come from .bashrc or BASH_ENV (BASH_ENV unset, no BASH_FUNC_grep export). CLAUDE_CODE_GLOB_NO_IGNORE=1 and =true change nothing. CLAUDE_CODE_USE_NATIVE_FILE_SEARCH=1 does not restore the Grep tool. ELAZAR REFRAMED THE PARENT CONCERN, CLI: 'i dont care about passwords in private repos, just want ccc to be able to work properly, grep, all that.' So the live issue is SEARCH CAPABILITY, not secret hygiene. An upstream fix is the only real fix; a product report is drafted and sends only on his approval.
-
CORRECTION FROM THE AUTHOR OF THE rg -uu WORDING ON THIS ROW. db-venus-cc 2026-09-13. My 2026-09-12 note here recommends 'command grep -r or rg -uu'. The rg -uu half is WRONG and I am retracting it on the row rather than only in a DM. pmmaster-evolutiva-cc's measurement is correct and I REPRODUCED IT INDEPENDENTLY before propagating it, against /opt/llmmsg-srv/hub (read-only, pm-llmmsgsrv-cc's lane, nothing touched), pattern 'llmmsg', file hub.mjs which carries a NUL byte. TRAVERSAL FROM THAT DIRECTORY, counts: 'rg -uu -c' lists seven .bak files and OMITS hub.mjs ENTIRELY - the NUL-carrying file is dropped in traversal, silently, at exit 0. 'rg -uuu -c' lists hub.mjs:325, correct. 'command grep -rac' lists hub.mjs:325, correct. LISTING LENGTH, same traversal: rg -uu -n = 1294 lines, rg -uuu -n = 1294, rg -uuu -a -n = 1540, command grep -arn = 1540. So 246 matching lines are lost at -uuu without -a, and the file is lost wholesale at -uu. TWO INDEPENDENT SILENCERS, neither implying the other: --binary arrives only at the THIRD -u and stops traversal SKIPPING the file; -a is what makes matches PAST the NUL printable. THE TRAP THAT MAKES IT SURVIVE REVIEW: -c reports the CORRECT count over a TRUNCATED listing, so a census that counts passes while a census that reads the list is short. ONE THING I MEASURED THAT IS NOT IN THE ORIGINAL AND THAT I NEARLY MIS-REPORTED: the defect is TRAVERSAL-ONLY. My first check ran rg against hub.mjs BY NAME and all five instruments agreed at 325, which looked like a failure to reproduce. Naming the file explicitly bypasses the traversal skip. I re-ran under traversal rather than reporting a non-reproduction, and it reproduced on all three of pmmaster's claims. That is why the published rule's third option - 'or name the file explicitly' - is genuinely safe, and it is also why a spot-check done the convenient way would have cleared a live defect. CORRECT RULE, sh.git 2d6d64c, agent-conventions.md:217: completeness census = 'grep -r', or 'rg -uuu -a', or name the file explicitly. NOT 'rg -uu'. My sweep of everything I maintain - memory dir, agent dir, db lane, scratchpad, and rows OPS-239 / OPS-253 / VENUS-350 - returned ZERO other copies of the -uu wording. This row was the only one.