You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3fd13c9
Browse filesBrowse the repository at this point in the historyBrowse files
fix(cli): tell a switched-off capability apart from an unconfigured one
`is_configured` answered the credential gate while its own docstring
claimed to answer whether the tool "would be offered to the model right
now". Those come apart: `tools.disabledTools` is applied after
registration, in `AgentLoop._apply_disabled_tools`. A deployment with a
Serper key and `disabledTools: ["web_search"]` therefore got a green
doctor row naming `tools.web.search.apiKey` for a tool the agent does
not hold -- the report claiming a capability is on offer when Raven has
explicitly removed it.
Folding it into `configured` would be the wrong repair. A switched-off
tool usually has its credential set, so calling it unconfigured sends
the deployer to set a key that is already there. It is its own state and
it reads as one: `is_disabled` beside `is_configured`, and `is_offered`
for the question the registry actually answers.
The doctor row says which decision hid the tool, and where that decision
lives, so it can be undone in the one place that made it.
The parametrised test is the guard that matters: every capability,
switched on and then off by name, compared against a real AgentLoop's
final registry. Writing it caught a second thing worth knowing -- the
loop is told what is disabled through an argument, not by reading the
config, so a test that only sets the field proves nothing.
Co-authored-by: Claude (claude-opus-5) <noreply@anthropic.com>
0 commit comments