Function should_route_to_decision_panel 

fn should_route_to_decision_panel(_tool_name: &str) -> bool

Whether a can_use_tool control_request for tool_name (anything except AskUserQuestion, which is always parked separately — see handle_control_frame) should be routed to the frontend decision panel instead of auto-allowed.

Hardcoded to false — deliberately inert. This is the one remaining product decision SPEC_DECISION_PROMPT_2026_04_24.md Phase 2 and SPEC_AGENT_CONTROL_PROTOCOL_2026_06_15.md §5 Phase 2 both leave open, and it is NOT safe to default it to “route everything non-trivial” — that spec’s own §7 risk section says so directly:

Permission chatter: --permission-mode default may route many tools through can_use_tool. Mitigation: auto-allow in the handler (Phase 1); consider --permission-mode acceptEdits or allow-rules to cut volume.

--permission-mode default is the mode baked into every persistent Claude agent’s launch args today (static CLAUDE in crates/srv/src/backend/providers.rs), and it routes most non-trivial tool calls through this control_request. Flipping this function to unconditionally true would turn every persistent Claude agent into a prompt-per-tool-call experience the instant it ships — a real regression, not a hypothetical one, and not something an engineering change should decide unilaterally.

The parking/decide mechanism this gate controls — park_tool_permission_request below and PersistentSubprocessController::decide_tool_permission — is complete and independently tested (see the “Phase 2 gate” tests in persistent/tests/send_input.rs, which call both directly); flipping this gate on is a policy call about which tools or modes actually warrant a prompt (a risk-tiering scheme per SPEC_DECISION_PROMPT_2026_04_24.md’s own speculative risk field, --permission-mode acceptEdits instead of default, or persisted allow-rules per that spec’s §6 — none of which exist yet), not an engineering task this function should pre-empt.