Is it possible to disable some of the tools (search_tool) either for single project or globally?

[aa956]

How to disable search_tool and enable bash find, grep - these were more reliable for Python projects?
May be per project, may be global switch.

For some Python projects I'm getting a lot of retries using search_tool where pattern is a filename.

Looks like model does not understand search tool is not working for finding filename like "some_module", retries with "some_module\.py" and finds nothing too.

Model then tries various variants of ls but as code is under ./src/module/some-more/subdirectories it's not found, then sometimes tries search_tool with pattern of content only like "class SomeModule" - this works.

Usually ends with model running ls -R on entire project, or tries to run some quick Python script with bash tool like python -c 'from pathlib import Path; print(list(Path(".").rglob("*.[pP][yY]")))'.

So not critical as sooner or later model finds a way to run the search or find the file.

All of that with Qwen 3.6 27B at IQ4_KS.

[mlhher]

I will need to evaluate these new additions thoroughly. It is similar from the researcher the ideas seem great but these smaller local models seem to have issue with them.

Maybe it is time to go for a plugin system.

Note that you should be able to disable the search tool using the config.json for now:

    "enabled_tools": {
      "search_tool": false
    }

Will need to see how to evaluate these long-term this is also the reason the PR for the researcher subagent is still open.

[aa956]

Still, disabling search does not enable grep.

Is there any way to enable grep without forking?

Search tool fails constantly for Qwen 3.8 27B when enabled:

  ◆ Using search_tool for: sync|linker|blobs
 │    The glob search didn't work as intended, so I'll rerun it with the correct pattern and check the reference scripts to confirm the intended sync    
 │    semantics.
 │
  ◆ Using search_tool for: hflink sync|linker|blobs
  ◆ Using search_tool for: dry_run|dry-run|force
  ◆ Using search_tool for: dry_run|dry-run|force
  ◆ Executing: grep -n 'blobs' temp/download-hf-models.sh temp/create-hf-cache-model-links.sh | head -30 in dir: /home/user/projects/hf-model-linker
 │    The include glob didn't filter as expected. Let me target the  temp/  reference scripts directly:
 │
  ◆ Using search_tool for: blobs
  ◆ Using search_tool for: hflink sync|test_linker|feat/
 │    Let me check the reference bash scripts' symlink mechanics (these inform the linker design) and confirm what path they symlink to:                 
 │
  ◆ Using search_tool for: ln -s|snapshots|readlink
 │    The search tool's gitignore filtering is hiding the  temp/  scripts. Let me read them directly:
 │

[aa956]

llama-cpp running unsloth's Qwen3.8-27B-UD-Q4_K_XL.gguf with Q8_0/Q8_0 kv cache on linux.

In this specific case model was trying to search through .gitignore'd directory (./temp in the project) where there was a copy of the reference implementation of the code that needed porting (bash script that was growing so large that it was a good idea to convert it to python).

I've probably just noticed it with Qwen 3.8 as it's incredibly persistent and tries and then retries a single action a few times, slightly varying the arguments, while other models, like Qwen 3.6, would just switch to another approach after the first failure.

Two more cases where search in the .gitignore'd directories could be useful:

• I'm often just cloning source library repositories or documentation repositories into the .gitignore'd dirs for temporary implementation reference (e.g. desktop host running late-cli for the raspberry pi targeting project using picamera2 library, clone of https://github.com/raspberrypi/picamera2 source code for reference). There's no point in adding library sources or docs to the project, even as git submodules, so clone into ignored location was the first idea for this.
• Python project virtual environment is usually .gitignore'd but as it contains sources of all of the referenced libraries, models often try to search the library sources for documentation comments even when not pointed there specifically. Usually try grep first - blocked, search tool second - does not find anything, then just run temporary python interpreter with the code to import library and print inspection results.

[mlhher]

Thank you! That helps a lot. Maybe then simply allowing the LLM to pass a parameter allowing for gitignored files to be included would help. I will look at it.

[mlhher]

@aa956 Please check if it works with #114

[aa956]

Yes, with #114 it now searches files in gitignored directories!
So this works for my use case.

For interesting observations: Is it possible to log the Researcher Subagent session?
I can view it on a proxy level but that's per request and not easy to combine as each tool call is logged separately.

Actually for now I'll paste some interesting snippets from the researcher's screen:

Model is confused using search_tool when pattern is not found - model doubts if the tool use is correct, even if the reason is just too restrictive regex. Nothing to do here probably, for example:

The search_tool probably requires a directory for path, or maybe it can handle files too

  ◆ Reading file ./temp/huggingface_hub/src/huggingface_hub/file...
  ◆ Reading file ./temp/huggingface_hub/src/huggingface_hub/file...
  Thoughts:
    ┃ Alright, let's check the signature and return value of `scan_cache_dir`, the signature of `snapshot_download` in the installed version (1.27.0) — in
    ┃ particular, the return type when `dry_run` is specified, and `HfApi().repo_info` for online resolution. I'll also check the `RepoInfo` class fields
    ┃ (like `commit_hash` / `sha`?).
    ┃
    ┃ Let's take a look at the `snapshot_download` function in `_snapshot_download.py`.
    ┃
  ◆ Using search_tool for: def snapshot_download|^class RepoInfo|commit_ha...
  ◆ Reading file ./temp/huggingface_hub/src/huggingface_hub/util...
  Thoughts:
    ┃ I can't find `snapshot_download` in `_snapshot_download.py`? Let me check the actual file. Maybe in version 1.27.0 `snapshot_download` is defined
    ┃ somewhere else. Let me search for `def snapshot_download` across the entire huggingface_hub src.
    ┃
  ◆ Using search_tool for: ^def snapshot_download
  Thoughts:
    ┃ The earlier search using `^class RepoInfo|commit_hash|def repo_info` against `_snapshot_download.py` didn't find a match — that's weird. Maybe the
    ┃ search only matched `def snapshot_download`. Wait, my pattern was `def snapshot_download|^class RepoInfo|commit_hash|def repo_info`, and the reason
    ┃ it returned "No matches found" was... hmm, actually it says "No matches found" yet now a match is being found. Maybe that file is gitignored
    ┃ (temp/huggingface_hub/.gitignore)? No, other files in temp/huggingface_hub were found without any issue. The earlier search was against the same
    ┃ path with the pattern `def snapshot_download|^class RepoInfo|commit_hash|def repo_info`... it returned no matches. Weird. Oh wait — in the previous
    ┃ call, the path was `.../temp/huggingface_hub/src/huggingface_hub/_snapshot_download.py` (a file, not a directory). The search_tool probably requires
    ┃ a directory for path, or maybe it can handle files too. This time, using a directory path, it worked. Alright.
    ┃
    ┃ So, let me read the overloads of `snapshot_download` and check the return type annotation.
    ┃
  ◆ Reading file ./temp/huggingface_hub/src/huggingface_hub/_sna...
  Thoughts:
    ┃ `snapshot_download` returns `str` (snapshot path) when not in dry-run. In other words, the commit hash can be extracted as the last component of the
    ┃ returned path (`snapshot_path.name`). However, there's also the method of using `HfApi().repo_info` or `api.repo_info` to resolve the commit SHA
    ┃ online. Let me check the return type of `HfApi.repo_info` in this version — `RepoInfo` with a `commit_hash` field? Let me search for `class
    ┃ RepoInfo` in hf_api.py.

Do I see it correctly that bash_tool grep call actually succeeded once (with pattern along the lines of wc -l file file file 2>/dev/null; grep), probably not related to #114 and would have slipped through current filter somehow too?:

  Thoughts:
    ┃ Check the huggingface_hub reference docs: package_reference/cache.md. This is the main file for feature 5. Read through it and find the relevant
    ┃ APIs: `scan_cache_dir`, `HfCacheInfo`, `HfRepoInfo`, `HfFileData`, `repo_folder_name`, `try_to_load_from_cache`, `HfApi().repo_info`,
    ┃ `cached_download`, `cache_info` CLI, `HfFolderInfo`? Actually, the docs for the newer huggingface_hub use the `HfCacheInfo`, `HfRepoInfo`, and
    ┃ `HfFileData` dataclasses. Let's check the actual files inside temp/huggingface_hub.
    ┃
  ◆ Executing: wc -l /home/aa956/projects/hf-model-linker/temp/huggingface_hub/docs/source/en/package_reference/cache.md /home/aa956/projects/hf-model-
  linker/temp/huggingface_hub/docs/source/en/guides/manage-cache.md /home/aa956/projects/hf-model-
  linker/temp/huggingface_hub/docs/source/en/package_reference/file_download.md /home/aa956/projects/hf-model-
  linker/temp/huggingface_hub/docs/source/en/package_reference/constants.md 2>/dev/null; grep -n "class Hf\|def scan_cache_dir\|def
  try_to_load_from_cache\|def repo_folder_name\|def repo_id_to\|class RepoIdAndRefs\|class FileNotCachedException\|def cached_folder_info\|def scan_cache"
  /home/aa956/projects/hf-model-linker/temp/huggingface_hub/src/huggingface_hub/_snapshot_download.py /home/aa956/projects/hf-model-
  linker/temp/huggingface_hub/src/huggingface_hub/utils/_cache_manager.py /home/aa956/projects/hf-model-
  linker/temp/huggingface_hub/src/huggingface_hub/reporeference.py 2>/dev/null | head -60
  Thoughts:
    ┃ The grep results are only showing part of the content. Let me read all of cache.md (63 lines), and search within the huggingface_hub source for the
    ┃ following APIs: `scan_cache_dir`, `HFCacheInfo`, `HFRepoInfo`, `HFFileData`, `try_to_load_from_cache`, `repo_folder_name`, `repo_id_to HFRepo`,
    ┃ `HfApi().repo_info`, `cached_folder_info`.
    ┃
  ◆ Reading file ./temp/huggingface_hub/docs/source/en/package_r...
  ◆ Executing: grep -n "^class \|^def \|^    def " /home/aa956/projects/hf-model-linker/temp/huggingface_hub/src/huggingface_hub/utils/_cache_manager.py |
  head -40
  Thoughts:
    ┃ I need to use search_tool instead of grep. Let me search for the class definitions and function signatures within _cache_manager.py.
    ┃
  ◆ Using search_tool for: ^(class \w+|def \w+|    def \w+)
  ◆ Using search_tool for: ^def |^class 
  Thoughts:
    ┃ The reporeference.py file might not exist. Let's check the fields of CachedRepoInfo/CachedRevisionInfo/CachedFileInfo (around lines 40-260), as well
    ┃ as the `try_to_load_from_cache` and `repo_folder_name` functions. Also, let's check the return type of `snapshot_download` in this version (1.27.0)
    ┃ and the `HfApi.repo_info` API too.

[mlhher]

The logging is something that I really need to implement. It has been talked about quite some times. The issue is that it is quite an extensive implementation. I will get to it when I can.

For the model being confused I will look into the returns the model gets from the tool. It might not offer helpful enough messages. On the other hand it might just be the model.

The grep bash gate was implemented by @giveen . I think it is correct to not implement it fully e.g. compared to cd but there might be edge cases where it might slip through. I will look into this.