- Shipped
- August 11, 2026 at 12:09 AM UTC
- Author
- kamo
- Commit
- ba24958
Nearly every gateable action in the product — dial an extension, email a member, open the AI assistant, play a recording, start a social conversation — is a bare **************** and the tool registry had no gate at all. Gating those call sites one at a time could never be complete: a dispatcher added later, or simply missed, routes straight around it. The check now lives in ToolWindowsContext's single tool:open handler, so every caller is covered. Actions that never pass through a tool window are gated where they live: attachments (including drag-drop and paste, which are the same capability by another route), growing a chat into a group, and the meeting entry points. That also settles three inconsistencies the audit found. Two of the three "invite to meeting" entry points checked organization.isMeet and the third did not; two of the three email entry points checked ACCESS_MAIL and the third did not; and dialling a member's extension from the roster had no VOIP check of any kind. All of them now agree. Capabilities default to locked — while the first load is in flight, if the call fails, and if an older backend omits the field. Guessing "allowed" would hand out paid features, which is the mistake the entitlement path already made once with its fail-open default.