If the server behind --permission-prompt-tool disconnects, checks now deny cleanly instead of using a stale tool.
What's wrong with this entry?
If the MCP server that supplied the tool named by --permission-prompt-tool is no longer connected in the session, permission checks are now denied with a message saying so, instead of being resolved against a stale tool.
- The wrapper checks the server's connection state at check time, and is also constructed in a do-nothing "deny" form up front when the server is already absent at startup.
- No flag involved; behaviour follows the session's MCP connection state.
its MCP server is not connected in this session.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.229
Permission-prompt-tool errors reportable without leaking tool names
Both mention prompt tool
-
v2.1.242
Groundwork for running tools on another machine over the device bridge
Both mention tool
-
v2.1.242
The remote bridge can push an attachment notice, including after compaction
Both mention tool