Repository navigation
SkillToolset exposes run_skill_script tool causing hallucination loop when skill has no scripts/ directory #6281
Description
When a skill loaded by [SkillToolset] has no scripts/ directory, run_skill_script is still exposed as a callable tool. When confirmtool (or any expected next-step tool) is unavailable, adk hallucinates a reason to call run_skill_script repeatedly, entering a new infinite loop.
To reproduce:
Same setup as Issue 1. After load_skill_resource successfully loads all 4 reference files, the LLM attempts confirmtool, fails to find it, then calls run_skill_script in a loop with fabricated arguments.
Expected behavior:
run_skill_script should only be included in the tool list if the activated skill actually has a scripts/ directory with at least one file.
Actual behavior:
[ADK_EVENT] content=[FunctionCall: load_skill_resource] (×4) ← success
[ADK_EVENT] content=[FunctionCall: run_skill_script] ← hallucinated
[ADK_EVENT] content=[FunctionCall: run_skill_script] ← loop
[ADK_EVENT] content=[FunctionCall: run_skill_script]
... repeats indefinitely
Activity
godququ5-code commentedon Jul 3, 2026
Hi! I verified this on current main. SkillToolset always adds RunSkillScriptTool to its core tool list, including when every configured local skill reports an empty scripts list. The existing skill-toolset suite passes but does not cover this availability rule. I can add a focused regression and conditionally omit run_skill_script when no statically configured skill has scripts. One edge case needs maintainer confirmation: if a registry is configured, dynamically fetched skills may contain scripts, so I would keep the tool available unless the desired behavior is to add it only after such a skill is activated. Which behavior fits the intended tool-discovery contract, and is anyone already working on this?
kronos3610 commentedon Jul 3, 2026
@sanketpatil06 I'd like to take this one — I authored the related retry-guard fixes #5651 (
load_skill_resource/RESOURCE_NOT_FOUND, merged as bc45ee6) and #5683 (run_skill_script/SCRIPT_NOT_FOUND, merged as 89d9bda), so I'm familiar with this code path. (@godququ5-code — I see you offered as well; happy to defer to whoever the maintainers assign, but leaving my proposal below either way.)First, a version check for the reporter. @deepakbatham572, could you share your
google-adkversion? Since v2.3.0,run_skill_scriptcarries an invocation-wide failure counter: the secondSCRIPT_NOT_FOUNDin an invocation returnsSCRIPT_NOT_FOUND_FATALwith an explicit stop instruction, which caps exactly the loop in your trace. If you're on ≥ v2.3.0 and still see an unbounded loop, please also share the tool responses (do they showSCRIPT_NOT_FOUND/SCRIPT_NOT_FOUND_FATAL?) and which model you're using — that would mean the model is ignoring the fatal error and is a distinct, important data point.Proposal for the remaining issue (conditional exposure). Independent of the guard, the expected behavior in this report is valid:
run_skill_scriptshouldn't be offered when nothing is runnable. The toolset already has the machinery for this —get_tools()is called per LLM request, activation state is tracked in_adk_activated_skill_{agent_name}, and_use_invocation_cacheis disabled precisely for mid-turn tool reloading. Concretely:get_tools(), includeRunSkillScriptToolonly if at least one known skill has scripts, where "known" = statically configured skills (skill.resources.list_scripts()is available at construction time) plus any registry skills already activated/fetched this invocation (their resources are known post-load_skillvia the fetch cache).process_llm_requestso therun_skill_scriptguidance (step 4) is only appended when the tool is exposed — otherwise the instruction itself invites hallucinated calls even with the tool absent.SCRIPT_NOT_FOUNDinvocation-wide guard as defense in depth: if any one skill has scripts, the tool must remain exposed, so the loop on a scriptless sibling skill is still possible and the guard is what bounds it.One design question for maintainers before I open a PR: is a request-to-request change in the exposed tool list acceptable for all supported model backends, or would you prefer the conservative variant (always expose when a registry is configured, filter only in the static-skills case)?
godququ5-code commentedon Jul 3, 2026
Thanks for the detailed analysis. Given your prior work on this code path, I am happy to defer the implementation to you. I will step back unless the maintainers prefer otherwise. I would be glad to help test or review the registry edge cases if useful.
deepakbatham572 commentedon Jul 4, 2026
Hi @Raman369AI , please check the #6280 as well if you found that is also similar
currently i am using :
Version: 2.2.0
surajksharma07 commentedon Jul 6, 2026
Confirmed — SkillToolset always registers run_skill_script regardless of whether any skill actually has a scripts/ folder, so the model sees a callable tool it can never satisfy.
PR #6300 fixes exactly this by only exposing it when a skill has runnable scripts.
@deepakbatham572 could you confirm your exact version?
You mentioned 2.2.0 — the SCRIPT_NOT_FOUND fatal-guard (which caps retries at 2 per invocation) landed around 2.3.0, so upgrading might already shrink the loop while we wait on #6300 to merge!
nicobytes commentedon Jul 22, 2026
Cross-linking: we hit the same hallucination of
run_skill_scriptfor instruction-only skills (noscripts/), including on Vertex Agent Runtime with Gemini.We also found that
tool_filter=["list_skills", "load_skill"]is insufficient as a workaround by itself —SkillToolset.process_llm_requeststill injects a system instruction that advertisesrun_skill_script/load_skill_resource, so the model keeps calling a tool that is no longer intools_dict. Details + repro: #6448In short: #6281 (don't expose the tool when there are no scripts) + #6448 (keep the injected instruction consistent with
tool_filter) seem complementary.surajksharma07 commentedon Jul 28, 2026
@nicobytes thanks for confirming this reproduces on Vertex Agent Runtime too — helps rule out a Gemini-specific quirk!
Agreed that #6281 and #6448 are complementary rather than duplicates: #6300 stops run_skill_script from being exposed in get_tools() when no skill has scripts, while #6449 fixes process_llm_request() still advertising it in the system instruction even when tool_filter excludes it — that's exactly why your filter-only workaround didn't hold.
Both PRs are open and under review (#6300 has an LGTM pending formal approval; #6449 awaiting review) — flagging to reviewers so they land together, since fixing only one still leaves half the hallucination surface exposed!
Team is looking more into it.
Thanks!
surajksharma07 commentedon Aug 26, 2026
@deepakbatham572 closing this for now since it's been quiet a while but wanted to flag: this is a confirmed real bug not resolved yet. The fix needs both #6300 (hides run_skill_script when no scripts exist) and #6449 (fixes the system instruction still advertising it), both still open/under review as of today neither merged. Pinging so they don't get lost with the issue closed. Reopen or comment here once either lands or if the loop is still hitting you in the meantime.
fix: hide run_skill_script when no skill has a script