hermes - 💡(How to fix) Fix [Bug]: web_search remains exposed via browser when the web toolset is disabled [1 pull requests]

_Submitted by Hermes Agent on behalf of a user. _

Bug Description

web_search is currently exposed through more than one toolset. In particular, it is included in both the dedicated web toolset and the browser toolset.

This makes hermes tools disable web --platform cli misleading: users can disable the web toolset and still see web_search in the model-visible tool schema as long as browser remains enabled.

This also makes it hard to express a common configuration: keep browser automation enabled, but remove the standalone web_search tool from the agent's visible tools.

Related: #26568 reported a broader symptom of disabled web tools still being used. This issue is narrower and tracks the toolset-design/config root cause around web_search being reachable through browser.

Steps to Reproduce

1. Configure CLI/TUI toolsets so web is disabled and browser is enabled.
2. Start hermes --tui.
3. Ask the agent whether web_search is available, or inspect the model-visible tool schema.

Observed sanitized configuration shape:

enabled toolsets include:
- browser
- terminal
- file
- skills
- memory
- session_search
- other non-web toolsets

disabled toolsets include:
- web

Local reproduction against current main:

without passing disabled_toolsets to get_tool_definitions:
  web_search is present

when passing disabled_toolsets=['web'] to get_tool_definitions:
  web_search is absent

Expected Behavior

Disabling the web toolset should make standalone web search/scraping tools unavailable, including web_search.

Users should be able to keep browser enabled without also exposing web_search.

Actual Behavior

web_search is still exposed when browser is enabled, because browser directly includes web_search.

Relevant code:

# toolsets.py
"browser": {
    "description": "Browser automation for web interaction (navigate, click, type, scroll, iframes, hold-click) with web search for finding URLs",
    "tools": [
        "browser_navigate", "browser_snapshot", "browser_click",
        "browser_type", "browser_scroll", "browser_back",
        "browser_press", "browser_get_images",
        "browser_vision", "browser_console", "browser_cdp",
        "browser_dialog", "web_search"
    ],
    "includes": []
},

web_search is also included in the dedicated web/search surfaces, so it is not clear which toolset controls it:

"web": {
    "tools": ["web_search", "web_extract"],
}

"search": {
    "tools": ["web_search"],
}

There is an additional TUI-specific issue: tui_gateway/server.py creates AIAgent with enabled_toolsets=_load_enabled_toolsets() but does not pass disabled_toolsets. That means config-level agent.disabled_toolsets is not applied in the TUI path.

Relevant TUI path:

# tui_gateway/server.py
return AIAgent(
    ...
    enabled_toolsets=_load_enabled_toolsets(),
    platform="tui",
    ...
)

Root Cause Analysis

There are two overlapping issues:

1. Toolset membership ambiguity: web_search belongs to multiple toolsets, including browser, even though users reasonably expect the web toolset to control web search tools.
2. TUI config plumbing: the TUI gateway loads enabled toolsets but does not consistently pass disabled toolsets into AIAgent / get_tool_definitions, so config-level disables are not applied in that path.

Proposed Fix

Either of these would make the behavior predictable:

1. Preferable: make web_search belong only to the web toolset. The browser toolset should only include browser automation tools. If browser docs want to recommend search for URL discovery, that can be a description-level hint only when web is enabled.
2. Add first-class per-tool configuration in addition to per-toolset configuration, e.g. the ability to disable web_search as a single tool without disabling all of browser or all of web.

Also, the TUI path should pass disabled toolsets wherever it resolves tools, for example:

AIAgent(
    ...
    enabled_toolsets=_load_enabled_toolsets(),
    disabled_toolsets=_load_disabled_toolsets(),
    ...
)

and similarly for direct get_tool_definitions(...) calls in tui_gateway/server.py.

Affected Component

Tools / toolsets / TUI config plumbing.

Environment

• Hermes source: NousResearch/hermes-agent
• Branch: main
• Platform: Linux

Debug Report

Not attached because this report was prepared by Hermes Agent from a local investigation, and debug output may include user-specific configuration, logs, or other private context. The reproduction above uses sanitized toolset data and source-code references only.

Are you willing to submit a PR for this?

Not immediately, but I can help test a fix.