hermes - 💡(How to fix) Fix [Bug]: cronjob tool can remain hidden if tool definitions are cached before gateway env is set [1 pull requests]

Bug Description

This is likely an edge case rather than a common plain-gateway startup bug. I am filing it because the repro uses only upstream modules and points to a cache invalidation boundary: tool availability can depend on environment variables, but the quiet-mode tool-definition cache does not include those env values.

Specifically, the cronjob tool can remain hidden if tool definitions are inspected before gateway.run sets HERMES_EXEC_ASK=1.

I hit this in a downstream setup that performs tool-visibility/status checks around the gateway. A plain hermes gateway run startup may not hit this ordering if nothing probes tool definitions before the gateway module finishes initializing.

However, the minimal repro below uses only upstream modules. The issue is not specific to any private tool or custom configuration.

Steps to Reproduce

1. In a clean detached v2026.5.28 worktree, run this script:

import os

for key in ("HERMES_GATEWAY_SESSION", "HERMES_EXEC_ASK", "HERMES_INTERACTIVE"):
    os.environ.pop(key, None)

from model_tools import get_tool_definitions

pre = [
    tool["function"]["name"]
    for tool in get_tool_definitions(
        enabled_toolsets=["cronjob"],
        quiet_mode=True,
    )
]

import gateway.run

post = [
    tool["function"]["name"]
    for tool in get_tool_definitions(
        enabled_toolsets=["cronjob"],
        quiet_mode=True,
    )
]

print({
    "pre": pre,
    "exec_ask": os.getenv("HERMES_EXEC_ASK"),
    "post": post,
})

1. Observe that importing gateway.run sets HERMES_EXEC_ASK=1.
2. Observe that cronjob is still absent from the second tool-definition lookup.
3. I also reproduced the same ordering on current origin/main (b1a25404b) using skip_tool_search_assembly=True.

Expected Behavior

After gateway.run marks the process as a messaging gateway approval context via HERMES_EXEC_ASK=1, cronjob should become visible, or any stale pre-gateway tool availability cache should be invalidated.

Actual Behavior

cronjob remains hidden because the earlier quiet_mode=True tool-definition result is reused.

Observed output from a clean detached v2026.5.28 worktree:

{'pre': [], 'exec_ask': '1', 'post': []}

Observed output from a clean detached current origin/main worktree:

{'pre': [], 'exec_ask': '1', 'post': []}

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

No response

Debug Report

Not included. I did not run `hermes debug share` because the repro is a minimal import/cache-order script using upstream modules, and my live deployment contains private/customized configuration.

Operating System

macOS 26.3

Python Version

Python 3.11.15

Hermes Version

v2026.5.28; also reproduced on origin/main b1a25404b

Additional Logs / Traceback (optional)

No traceback. Minimal repro output:


{'pre': [], 'exec_ask': '1', 'post': []}

Root Cause Analysis (optional)

tools.cronjob_tools.check_cronjob_requirements() enables the tool only when one of these env vars is truthy:

• HERMES_INTERACTIVE
• HERMES_GATEWAY_SESSION
• HERMES_EXEC_ASK

model_tools.get_tool_definitions(..., quiet_mode=True) memoizes the filtered tool list.

In gateway/run.py, HERMES_EXEC_ASK=1 is set during module initialization, but not before every possible prior import/probe of model_tools. If another path in the same process calls get_tool_definitions() first, cronjob can be cached as unavailable. Importing gateway.run later sets HERMES_EXEC_ASK=1, but the stale cached tool list is still reused.

Proposed Fix (optional)

A few possible approaches:

1. Set the regular gateway env markers (HERMES_QUIET, HERMES_EXEC_ASK) earlier, before any imports/config validation paths can probe tool availability, and invalidate already-loaded tool/check caches after setting them.
2. Include the relevant tool-availability env fingerprint in the get_tool_definitions cache key, so env changes that affect check functions cannot reuse stale results.
3. Expose a small explicit cache invalidation call for gateway startup after it sets process-level tool context.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR