{"version":"2.1.295","anchor":"parked-permission-prompts-answer-first-wait-and-richer-tele","canonical_anchor":"parked-permission-prompts-answer-first-wait-and-richer-tele","heading":"Resumed remote workers can wait for a permission answer before carrying on","tier":"internal","area":"Sessions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.295\/e\/parked-permission-prompts-answer-first-wait-and-richer-tele","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.295","markdown":"### Resumed remote workers can wait for a permission answer before carrying on\n\nA remote worker that restarts can now wait a short, limited time for an unread permission answer before it moves on\n\n**Unclear.** It is not clear whether the answer-first wait is switched on by default or what turns it on.\n\n**What**\n\nSome Claude Code sessions run on a remote worker, a separate machine that does the work while you watch and approve things. Sometimes Claude has to stop and ask your permission before an action, and the worker restarts while that question is still waiting. When the worker resumes and an answer has arrived that it has not read yet, it can now wait a limited time for that answer before going ahead. This wait only happens when an internal setting tells it to put the answer first.\n\nOther changes in the same area:\n\n- Interrupting, rewinding or denying now explicitly handles the turn that was cut off, meaning the step Claude was in the middle of.\n\n- The usage records sent when a permission answer is dropped now say what kind of answer it was: deny, allow once, or allow with changes.\n\n- Those records also say whether the answer added allow rules, changed the permission mode, or added folders.\n\n**Why**\n\nThis makes it less likely that a permission answer you gave gets lost or applied twice when a remote worker restarts.\n\n- Area: Sessions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no"}