{"version":"2.1.280","anchor":"sdkremote-elicitation-handling-reworked-around-session-tear","canonical_anchor":"sdkremote-elicitation-handling-reworked-around-session-tear","heading":"Pending-prompt and elicitation tracking reworked","tier":"internal","area":"SDK","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/sdkremote-elicitation-handling-reworked-around-session-tear","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Pending-prompt and elicitation tracking reworked\n\nClaude Code now tracks pending prompts and elicitations more precisely so idle\/running status and unanswered questions are handled correctly\n\n**What**\n\n- The handling of elicitations (requests that pause a session waiting for input) was rewritten: they now register in a shared list of pending actions, can be marked as background prompts, and when a session tears down, a surviving pending action (preferring a \"can use tool\" request) is now republished instead of every pending request simply being rejected.\n\n- The check used to decide whether a session is idle or still running was simplified to a single `hasPendingPrompt()` check (with a new `promptLeftStanding` guard), replacing two separate checks that used to look at pending permission requests and pending user-dialog requests independently.\n\n**Why**\n\nThis makes session status (idle vs. running) and unanswered-question handling more reliable, especially for SDK and remote\/cloud sessions, so a session isn't reported as idle while a question is still waiting for an answer, and pending requests aren't dropped unnecessarily when a session ends.\n\n- Area: SDK\n- Names: `republishPendingAction`\n- Tier: Under the hood\n- Useful: 3\/5\n- Signal: 3\/5"}