{"version":"2.1.251","anchor":"backgrounded-commands-record-whether-the-move-was-to-deliver","canonical_anchor":"backgrounded-commands-record-whether-the-move-was-to-deliver","heading":"Backgrounded commands record whether the move was to deliver a queued message","tier":"internal","area":"Bash","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251\/e\/backgrounded-commands-record-whether-the-move-was-to-deliver","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251","markdown":"### Backgrounded commands record whether the move was to deliver a queued message\n\nBackgrounded commands now record whether they moved aside to deliver a queued message.\n\n**What**\n\nInternal shell state now distinguishes a command pushed to the background so a message queued for the model could reach it from one backgrounded for other reasons, such as a plugin aborting the turn. The PowerShell command result carries this marker alongside the existing background fields. None of it surfaces in the interface while using Claude Code.\n\n**Details**\n\n- a `backgroundedToDeliverMessage` field is set on the result of a backgrounded PowerShell command and passed through with the other background fields\n- the field is documented as true only when the command was moved to the background so a message queued for the model could reach it\n- commands backgrounded for any other cause leave the field unset, so the reason for backgrounding is no longer ambiguous internally\n- no flag, setting or environment variable exposes this, and there is no user-visible output change in this build\n\n**Evidence**\n\n`backgroundedToDeliverMessage: b.backgroundedToDeliverMessage`, `True if the command was moved to the background so a message queued for the model could reach it`\n\n- Area: Bash\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}