Description
kb_search accepts a scope parameter to restrict the search to a specific KB instance ("all" | "local" | "remote" | an instance name), but its AI-residency policy check does not respect it. Calling kb_search(query=..., scope="SomeInstance") is blocked outright if any registered KB instance (e.g. the primary local KB) has ai_residency=local_models_only and the session's provider isn't a local model — even when the call is explicitly scoped away from that instance entirely.
Observed error:
AI-residency policy: KB 'primary' is set to local_models_only, and this session's AI provider (none/unauthenticated) isn't a local model. 'kb_search' scans across all registered KBs, so it's blocked outright rather than silently omitting that KB's results — use kb_get/kb_search with an explicit scope/kb argument that excludes it, or switch to a local (Ollama) provider.
The error message itself says to "use kb_search with an explicit scope/kb argument that excludes it" — but that's exactly what scope="SomeInstance" already does, and the call was still blocked. The residency gate appears to run before scope filtering is applied, rather than after.
Steps to reproduce
- Have at least two registered KB instances on the same machine, one with
ai_residency=local_models_only (e.g. the primary/local KB).
- Register a second instance with default/open residency (e.g. via
kb_register).
- Call
kb_search(query="...", scope="<second-instance-name>") from a non-local-model session.
- Observe: blocked with the residency error, even though
scope excludes the restricted instance.
kb_get (single-node fetch by id, not a cross-KB scan) is unaffected — this appears specific to kb_search's scanning path.
Suggested fix
Apply the scope filter before evaluating the AI-residency policy, so a call explicitly scoped away from a local_models_only instance is not blocked by that instance's policy. The residency check should only fire for instances that are actually within the resolved scope.
Context
Found while developing a portable KB project (dev-practices-kb) meant to be kb_register'd and queried via kb_search(scope=...) against a specific named instance — the intended use case this bug directly blocks. Related to, but distinct from, #350 (kb_search_context has no scope param at all).
Description
kb_searchaccepts ascopeparameter to restrict the search to a specific KB instance ("all" | "local" | "remote" | an instance name), but its AI-residency policy check does not respect it. Callingkb_search(query=..., scope="SomeInstance")is blocked outright if any registered KB instance (e.g. the primary local KB) hasai_residency=local_models_onlyand the session's provider isn't a local model — even when the call is explicitly scoped away from that instance entirely.Observed error:
The error message itself says to "use kb_search with an explicit scope/kb argument that excludes it" — but that's exactly what
scope="SomeInstance"already does, and the call was still blocked. The residency gate appears to run before scope filtering is applied, rather than after.Steps to reproduce
ai_residency=local_models_only(e.g. the primary/local KB).kb_register).kb_search(query="...", scope="<second-instance-name>")from a non-local-model session.scopeexcludes the restricted instance.kb_get(single-node fetch by id, not a cross-KB scan) is unaffected — this appears specific tokb_search's scanning path.Suggested fix
Apply the
scopefilter before evaluating the AI-residency policy, so a call explicitly scoped away from alocal_models_onlyinstance is not blocked by that instance's policy. The residency check should only fire for instances that are actually within the resolved scope.Context
Found while developing a portable KB project (
dev-practices-kb) meant to bekb_register'd and queried viakb_search(scope=...)against a specific named instance — the intended use case this bug directly blocks. Related to, but distinct from, #350 (kb_search_contexthas noscopeparam at all).