Malformed permission requests from workers or SDK clients are denied immediately instead of reaching your dialog.
What's wrong with this entry?
Permission requests arriving from a worker, an SDK client or a direct socket connection are now checked for shape first. A structurally malformed permission request gets an immediate deny reading "Malformed permission request from worker" rather than reaching the approval dialog.
- A
can_use_toolmessage whose request id is not a string is dropped and logged, since there is no way to reply to it. - The direct socket handler rejects control requests that carry no request object or no string request id.
- The SDK message adapter drops conversation-reset messages without a string new conversation id, and tolerates a result whose errors field is not an array instead of trying to render it.
- Unconditional, no flag.
Malformed permission request from worker, [DirectConnect] Dropping control_request without a request object / request_id
Strings lifted out of the shipped bundle, so the claim above can be checked against them.