A Provider boundary can grant draft-reading and submission capabilities to too many descendants
Source references: 3The guide explicitly treats the Provider boundary as the access boundary: components inside it can read messages and attachments or call submit even outside Composer.Frame. If an application wraps a large component tree or includes less-trusted third-party components, those descendants receive more capability than the visible UI structure suggests.
Affected descendants could read unsent content, modify shared state, or trigger forwarding/submission. The evidence does not show external disclosure or automatic execution; the risk depends on the Provider's scope and its descendants when this pattern is implemented.
This is a supported architectural risk, not evidence of an actual leak. The guide actively treats Provider scope as sufficient for sharing state, and its example lets descendants outside the Frame invoke submit and read message text and attachments. If an application wraps components that do not need these powers—or less-trusted third-party components—in the same Provider, they may gain draft-reading or submission capability. This is example code and is not executed by the Skill itself. Users can ask the author to clarify that Context is not a security boundary and to recommend the smallest trusted Provider subtree.
The provider boundary is what matters—not the visual nesting. Components thatneed shared state don't have to be inside the `Composer.Frame`. They just needto be within the provider.Show 2 other places
// This button lives OUTSIDE Composer.Frame but can still submit based on its context!function ForwardButton() { const { actions: { submit }, } = use(ComposerContext) return <Button onPress={submit}>Forward</Button>}// This preview lives OUTSIDE Composer.Frame but can read composer's state!function MessagePreview() { const { state } = use(ComposerContext) return <Preview message={state.input} attachments={state.attachments} />}The ForwardButton lives outside the Composer.Frame but still has access to thesubmit action because it's within the provider. Even though it's a one-offcomponent, it can still access the composer's state and actions from outside theUI itself.**Key insight:** Components that need shared state don't have to be visuallynested inside each other—they just need to be within the same provider.