{"version":"2.1.280","anchor":"request-user-dialog-bridge-logs-and-handles-malformed-resu","canonical_anchor":"request-user-dialog-bridge-logs-and-handles-malformed-resu","heading":"request_user_dialog bridge logs and handles 'malformed' results separately","tier":"internal","area":"Elsewhere","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/request-user-dialog-bridge-logs-and-handles-malformed-resu","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### request_user_dialog bridge logs and handles 'malformed' results separately\n\nMalformed dialog responses from the client now get their own warning log\n\n**What**\n\nWhen the `request_user_dialog` bridge feature receives a response from the client that it cannot read (\"malformed\"), it used to be treated the same as a cancelled dialog, silently falling back to the default answer. It now logs a warning specifically for the unreadable case before falling back, instead of grouping it silently with cancellations.\n\n**Why**\n\nThis makes it easier to notice and diagnose cases where a client sent a response Claude Code couldn't parse, rather than having that failure look identical to the user simply cancelling the dialog.\n\n- Area: Elsewhere\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}