ConversationRuntime already performs permission-policy checks and interactive approvals before dispatching a tool. The CLI tool executor was routing those same tool calls back through GlobalToolRegistry::execute, which re-ran the enforcer without a prompter and flipped approved bash calls back into denials.
Add a preauthorized execution path for runtime-dispatched tools, keep registry enforcement for direct callers, and format the files that were already tripping rustfmt on main.
Constraint: CI on main was failing both cargo fmt and the mock parity harness after permission enforcement landed
Rejected: Remove registry enforcement globally | would reopen direct-dispatch permission gaps
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Use execute_preauthorized only after ConversationRuntime or an equivalent caller has already completed permission gating
Tested: cargo fmt --all --check; cargo test -p rusty-claude-cli; cargo test -p tools
Not-tested: Full workspace test matrix beyond the Rust CI workflow targets
Add McpToolRegistry in crates/runtime/src/mcp_tool_bridge.rs and wire
it into all 4 MCP tool handlers in crates/tools/src/lib.rs.
Runtime additions:
- McpToolRegistry: register/get/list servers, list/read resources,
call tools, set auth status, disconnect
- McpConnectionStatus enum (Disconnected/Connecting/Connected/AuthRequired/Error)
- Connection-state validation (reject ops on disconnected servers)
- Resource URI lookup, tool name validation before dispatch
Tool wiring:
- ListMcpResources: queries registry for server resources
- ReadMcpResource: looks up specific resource by URI
- McpAuth: returns server auth/connection status
- MCP (tool proxy): validates + dispatches tool calls through registry
8 new tests covering all lifecycle paths + error cases.
Bridges to existing McpServerManager for actual JSON-RPC execution.