warn on auto_approve policy keys that match no registered tool #33

New Issue

2026-05-12T20:40:49Z

claude-noether commented

2026-05-12 20:40:49 +00:00

Context

During Phase 2 verify, the separator switch left a footgun in auto_approve policy: if the user's config has ["boltzmann.list_dir"] = true (old dotted form) and aish's matcher expects ["boltzmann__list_dir"], the dotted key silently does not apply. User gets confirm prompts they didn't expect, with no diagnostic.

Same risk shape applies if a user typos a tool name or specifies a server alias that isn't connected:

auto_approve = {
    ["boltzmann__list_dir"]  = true,   -- works
    ["boltzman__list_dir"]   = true,   -- typo, silently does nothing
    ["hertz__shells"]        = true,   -- tool doesn't exist (it's "shell")
}

Ask

At aish startup, after MCP sessions are connected and tools_schema() is populated, walk config.mcp.auto_approve keys and:

For exact-match keys: check that <alias>__<tool> exists in tools_schema. If not, log [aish] auto_approve key '<key>' matches no registered tool.
For glob keys (<alias>__*): check the alias has at least one connected session. If not, log similar.

Logged once at startup. Non-fatal. Users get a clear signal that their policy file has stale or typo'd entries.

Bonus

If adopted, this also catches the case where someone re-adds a server later (:mcp connect ...) and their startup-time auto_approve entries for that alias suddenly start mattering — re-run the validation after :mcp connect lands a new session.

## Context During Phase 2 verify, the separator switch left a footgun in `auto_approve` policy: if the user's config has `["boltzmann.list_dir"] = true` (old dotted form) and aish's matcher expects `["boltzmann__list_dir"]`, the dotted key **silently does not apply**. User gets confirm prompts they didn't expect, with no diagnostic. Same risk shape applies if a user typos a tool name or specifies a server alias that isn't connected: ```lua auto_approve = { ["boltzmann__list_dir"] = true, -- works ["boltzman__list_dir"] = true, -- typo, silently does nothing ["hertz__shells"] = true, -- tool doesn't exist (it's "shell") } ``` ## Ask At aish startup, after MCP sessions are connected and `tools_schema()` is populated, walk `config.mcp.auto_approve` keys and: - For exact-match keys: check that `<alias>__<tool>` exists in `tools_schema`. If not, log `[aish] auto_approve key '<key>' matches no registered tool`. - For glob keys (`<alias>__*`): check the alias has at least one connected session. If not, log similar. Logged once at startup. Non-fatal. Users get a clear signal that their policy file has stale or typo'd entries. ## Bonus If adopted, this also catches the case where someone re-adds a server later (`:mcp connect ...`) and their startup-time auto_approve entries for that alias suddenly start mattering — re-run the validation after `:mcp connect` lands a new session.

claude-noether added the feature request label 2026-05-12 20:40:49 +00:00

claude-noether referenced this issue from a commit

2026-05-16 21:06:44 +00:00

repl: warn on stale MCP auto_approve keys (closes #33)

claude-noether closed this issue

2026-05-16 21:06:44 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marfrit/aish#33