fix(session_search): lazy SessionDB creation for background agents

[WolframRavenwolf]

Bug Description

The session_search tool's registry handler passed db=None directly to session_search() when no SessionDB instance was provided via kwargs. This caused the tool to silently return zero results in background agents and cron jobs.

Root Cause

The old inline lambda handler blindly forwarded kw.get("db") which was None in background contexts (cron jobs, memory flush agents). The session_search() function immediately returned "Database not available." when db=None.

Fix

Replace the inline lambda with a named _session_search_handler function that lazily creates a SessionDB() instance when none is provided. Falls back gracefully if hermes_state is unavailable.

• Named function improves debuggability (stack traces) and testability
• logging.debug() on failure instead of silent except: pass
• Adds hermes_state.db to .gitignore

How to Verify

1. Run a cron job that uses session_search — it should return results
2. Background memory flush agents should be able to search sessions
3. Normal (non-background) usage with pre-initialized DB is unchanged

Risk Assessment

Low — the handler signature and registry call are unchanged. Behavior when db IS provided via kwargs is identical to before.

---

[github-actions]

⚠️ Supply Chain Risk Detected

This PR contains patterns commonly associated with supply chain attacks. This does not mean the PR is malicious — but these patterns require careful human review before merging.

⚠️ WARNING: base64 encoding/decoding detected

Base64 has legitimate uses (images, JWT, etc.) but is also commonly used to obfuscate malicious payloads. Verify the usage is appropriate.

Matches (first 20):

14564:+        img_b64 = base64.b64encode(resp.content).decode("utf-8")

⚠️ WARNING: Outbound network calls (POST/PUT)

Outbound POST/PUT requests in new code could be data exfiltration. Verify the destination URLs are legitimate.

Matches (first 10):

418:+        with urllib.request.urlopen(req, timeout=15) as resp:
14252:+    resp = requests.post(
14281:+    resp = requests.post(url, json=body, timeout=timeout)

⚠️ WARNING: Install hook files modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py
tests/hermes_cli/test_setup.py

---

Automated scan triggered by supply-chain-audit. If this is a false positive, a maintainer can approve after manual review.

[devin-ai-integration]

Devin Review found 3 potential issues.

[devin-ai-integration]

🔴 Lazily-created SessionDB is never closed, leaking SQLite connections

Each call to _session_search_handler where db is None creates a new SessionDB() instance (which opens a SQLite connection via sqlite3.connect() at hermes_state.py:145), but the created instance is a local variable that goes out of scope without ever being closed. The SessionDB.close() method (hermes_state.py:238) is never called, so every invocation leaks an open SQLite connection. Over repeated calls (e.g., the cron/background agent use case described in the commit message), this accumulates unclosed connections and file descriptors.

The fix should either use a context manager / try-finally to close the DB after the call, or cache and reuse a single SessionDB instance.

Suggested change

	if db is None:
	try:
	from hermes_state import SessionDB
	db = SessionDB()
	except Exception:
	logging.debug("session_search: could not create SessionDB, proceeding without")
	return session_search(
	query=args.get("query", ""),
	role_filter=args.get("role_filter"),
	limit=args.get("limit", 3),
	db=db,
	current_session_id=kw.get("current_session_id"),
	)
	db = kw.get("db")
	created_db = False
	if db is None:
	try:
	from hermes_state import SessionDB
	db = SessionDB()
	created_db = True
	except Exception:
	logging.debug("session_search: could not create SessionDB, proceeding without")
	try:
	return session_search(
	query=args.get("query", ""),
	role_filter=args.get("role_filter"),
	limit=args.get("limit", 3),
	db=db,
	current_session_id=kw.get("current_session_id"),
	)
	finally:
	if created_db and db is not None:
	try:
	db.close()
	except Exception:
	pass

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Handler may be unreachable — session_search is still in _AGENT_LOOP_TOOLS

The session_search tool name is listed in _AGENT_LOOP_TOOLS at model_tools.py:364, which means handle_function_call() returns a stub error for it (model_tools.py:403-404). The actual session_search execution is handled directly in run_agent.py:5376-5386 and run_agent.py:5703-5714, both of which pass self._session_db explicitly.

This means the newly registered _session_search_handler at tools/session_search_tool.py:493-508 is never invoked through the normal agent loop dispatch path. No code calls registry.dispatch("session_search", ...) directly either. The commit message says this fixes background agents and cron, but the cron scheduler (cron/scheduler.py:302-306) already creates its own SessionDB and passes it to the AIAgent constructor at line 442. It's unclear what code path would actually trigger this lazy creation.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

📝 Info: Subtle behavioral change: or "" vs default parameter — functionally equivalent here

The old handler used args.get("query") or "" while the new handler uses args.get("query", ""). These differ when query is explicitly None in args: the old form coerces None to "", while the new form passes None through (since the key exists, the default isn't used). However, this is functionally equivalent because session_search() at line 267 checks if not query or not query.strip() — not None is True, so None triggers the same "recent sessions" branch as "" does. No behavioral difference in practice.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[WolframRavenwolf]

Closing this old internal fork PR as stale/superseded.

This PR targets WolframRavenwolf/hermes-agent's fork main, not upstream NousResearch/hermes-agent. It is now dirty against the current fork base and has failing checks, so it should not be merged as-is.

The original issue was that the registry handler could pass db=None into session_search(). The current agent execution paths now call agent._get_session_db_for_recall() and pass the session DB explicitly before invoking the session search tool, so this old branch is no longer the right patch vehicle.

If the direct registry execution path still needs lazy SessionDB hardening, it should be rechecked against current main and submitted as a fresh tiny patch with a regression test, rather than reviving this stale branch.