The current implementation of Plan Mode transitions relies on a manual synchronization method (syncPlanModeTools) in the Config class. This method is responsible for imperatively registering and unregistering the enter_plan_mode and exit_plan_mode tools from the ToolRegistry whenever the application's ApprovalMode changes.

This approach presents several architectural and maintainability challenges:

1. State Fragmentation: Tool availability is managed in two different ways. Most tools are filtered declaratively by the PolicyEngine, but plan-related tools are managed via imperative registration/unregistration. This split makes it difficult to reason about the total set of tools available to the model at any given time.
2. Fragile Lifecycle Management: Because these tools are added and removed dynamically, the system must ensure that syncPlanModeTools is called at every possible entry point where the mode might change (initialization, mode switches, auth refreshes). Missing a single call-site can result in "ghost tools" appearing in inappropriate modes (e.g., exit_plan_mode being available while in YOLO mode).
3. Policy Inconsistency: The existing PolicyEngine is designed to be the single source of truth for tool visibility. By bypassing the policy engine for plan tools, we lose the ability to override or audit these specific tool permissions using the standard TOML-based policy hierarchy (Workspace, User, or Admin tiers).
4. Unnecessary Complexity: Manually managing the presence of tools in the registry adds boilerplate to the Config class that duplicates functionality already present in the PolicyEngine's DENY decision logic.

The management of enter_plan_mode and exit_plan_mode should be unified with the rest of the system's tool governance. These tools should remain registered in the registry (if Plan Mode is enabled) and their visibility should be controlled declaratively via the PolicyEngine based on the current ApprovalMode.