{"version":"2.1.277","anchor":"cancel-async-message-logic-unified-between-host-and-remote-c","canonical_anchor":"remote-bridge-sessions-can-now-cancel-an-in-flight-async-mes","heading":"Remote Control sessions can now cancel a single in-flight async message","tier":"use","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/cancel-async-message-logic-unified-between-host-and-remote-c","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Remote Control sessions can now cancel a single in-flight async message\n\nClaude.ai Remote Control bridge sessions can now cancel one specific async message instead of interrupting the whole turn\n\n**What**\n\nRemote-bridge sessions (used by Remote Control, i.e. controlling Claude Code from claude.ai) gained a new `onCancelAsyncMessage` handler alongside the existing `onInterrupt`, `onStopTask`, and `onBackgroundTasks` callbacks. This lets a specific async message be cancelled without interrupting the entire turn.\n\nThe cancellation logic itself (finding the in-flight message, dequeuing matching messages, marking a cancel as pending) was pulled out of its previous inline implementation into a shared helper that takes a source, either `'host'` or `'remote_client'`. The remote-control bridge's `onCancelAsyncMessage` calls this helper with `'remote_client'`, so it only cancels messages that originated from the bridge, and if nothing is queued yet, it withdraws the in-flight ingest instead of just marking a pending cancel.\n\n**Why**\n\nThis gives Remote Control sessions finer-grained control: a specific queued or in-flight message can be cancelled on its own, rather than the only option being to interrupt the whole turn.\n\n- Area: Remote Control\n- Names: `cancel_async_message`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 3\/5"}