SendMessage and team mailbox internals switched to a detached 'ask' permission callback
The SendMessage tool's cross-machine and team-mailbox permission checks now go through a detached ask callback and accessor functions instead of passed-in state objects
Under the hoodTier: how much it should matter to you
1Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
Team MessagingArea: what it touches
Internal ChangesKind: in v2.1.269,
Internal ChangesSection of the release
What
In the SendMessage tool's bridge/Remote Control send path, the permission-check helper used to be called directly with context and canUseTool. It's now invoked with an ask callback that calls the tool's canUseTool function with { detached: true }. This affects the isolatePeerMachines approval flow (the "isolatePeerMachines is enabled: sending to ... needs your approval" prompt) and the message-post call, which now takes { tool, sessionId, message, assistantMessage } instead of also passing context and canUseTool directly.
The team-messaging tool's internal resolver for mailbox, live-agent, stopped-agent, and cloud-session cases now reads application state and message history through accessor functions (resolverState(), messages()) instead of a captured state snapshot. Resuming or asking permission for a stopped or cloud agent is now routed through a wrapping effect call using the same detached ask pattern, rather than passing canUseTool/toolUseContext directly.
Why
This is an internal plumbing change to how permission checks are requested for cross-machine and team messaging, replacing direct state/context passing with callbacks and accessors; it's not expected to change what approval prompts look like to a user.
