[walcz-de]

Two small, related robustness fixes in tools.go for local-model tool selection. We hit these repeatedly in production (agent pool via LocalAI) — 4 hard turn-failures in one evening across two different Qwen-class local models.

1. The error hides the chosen name (pickTool)

When the model's chosen tool can't be resolved, pickTool returned a bare chosen tool not found. The name was only xlog.Debug-logged, so operators running at info level saw repeated failures with zero diagnosability. Now: chosen tool %q not found.

2. Tools.Find matched exact-only

Local models routinely emit namespaced / case / separator variants — functions.coach_regeln, Coach_Regeln, tools/coach_regeln — each of which missed and became a hard failure. Find now keeps exact match as the fast path and adds a lenient fallback that only triggers on a miss: it strips a leading namespace segment (functions./tools//ns::), case-folds, and treats - ≡ _. When an exact match exists it is always returned, so existing resolutions are unaffected (covered by a test).

Tests

Table-driven tests for normalizeToolName, lenient Find, and the exact-wins-over-lenient guarantee. go test, go vet, gofmt clean.

Related in spirit to #60 / #62: helper/selection steps benefit from diagnosability and tolerance of model quirks. Happy to adjust (e.g. gate the lenient match behind an option) if preferred.

🤖 Generated with Claude Code

[mudler-agent]

Thanks for this. Lenient matching helps local models, but as written it lets the name that approval sees differ from the tool that runs, which matters for embedders that gate tool calls by name.

The approved name is not the executed tool. pickTool stores the model's spelling in ToolChoice.Name (tools.go ~L837 on main: Name: toolName), and the tool-call callback receives that ToolChoice (~L1693). Execution then resolves it again with tools.Find(tc.Name) (~L1810, and ~L1862/L1911 on the other paths), which this PR makes lenient. So a model that calls Bash or functions.bash gets the bash tool executed, while the callback sees Bash.

In nib (the main embedder), a PreToolUse hook configured for bash then does not fire for that call. In auto-approve mode, hooks are the only gate. Name-based approval rules also stop matching; those fall back to prompting, which is safe but noisy.

Ambiguous matches. normalizeToolName keeps only the segment after the last ., / or :, so github/list_issues and gitlab/list_issues both become list_issues, and Find returns whichever comes first.

Suggested fix:

1. When the lenient pass matches, rewrite ToolChoice.Name to the resolved tool's real name before any callback runs (in pickTool and in the native tool-call path), so what gets approved is what runs.
2. Only accept a lenient match when exactly one tool matches. On two or more, treat it as not found, and name the candidates in the error.
3. A test that the callback receives the canonical name for a lenient match, and one for the ambiguous case.

The error-message change (chosen tool %q not found) is good as is.

[walcz-de]

Thanks for the careful review — both points were real. Updated and rebased on current main (single commit b2f239c):

1. Approved name = executed tool. Before any tool-call callback runs, every selected tool's name is rewritten to the real name of the tool it resolves to (Tools.canonicalizeToolChoice). That happens in pickTool (both the single and the multiple selection) and once more in ExecuteTools right after the selection, which also covers native tool calls that carry the model's spelling. So a model that calls Bash gets bash both approved and executed, and a PreToolUse hook for bash fires.
2. Only unique lenient matches. Find accepts a lenient match only when exactly one tool matches. github/list_issues + gitlab/list_issues asked for as list_issues → not found, and the pickTool error names both candidates (chosen tool "list_issues" not found: ambiguous, matches github/list_issues, gitlab/list_issues). Exact names still resolve.
3. Tests (tools_lenient_test.go): the callback receives the canonical name for Echo, functions.echo, tools/echo end to end through ExecuteTools, and the tool runs once; ambiguous Find returns nil and the error names both candidates; end to end an ambiguous call runs neither tool. Counter-checked: without the canonicalization the callback sees the model's spelling, without the uniqueness rule the first tool is picked and run.

The non-e2e suite passes; "Sub-Agent Spawning — Background agent spawning" fails occasionally, but it does so on untouched main as well (1 in 4 runs on each here), so it's pre-existing timing flakiness rather than this change. The [e2e] specs need a live LocalAI and weren't run.