Summary
Safety fixes for the Critical Action PIN. Update if you use the PIN, or if any device, scene or script has "lock" in its name.
- A device with "lock" in its name no longer controls a door lock. "Turn off the kitchen clock", or turning on a scene named "Unlock", was turned into a lock command, and when no lock had that name, the nearest-named lock was used. With the PIN on, the unlock was held for the PIN; with no PIN, the door unlocked at once. Lock and alarm calls are now recognized the way Home Assistant matches names (#782).
- Scripts and scenes are checked by what they do. A script or scene that unlocked a door or opened the garage ran with no PIN unless a rule named it. Now it asks for the PIN, while a bedtime scene that only locks up does not (#775).
Patch release on top of 3.44.1; nothing else changes. The langchain provider version ranges already merged to main ship in the next monthly release.
Details
Fixed
- Turning a device on or off no longer acts on a door lock because "lock" appears somewhere in the device's name. Before, any on/off request whose name contained those letters, such as "Kitchen Clock", "Block Heater" or a scene called "Unlock" or "Lock Up", was rewritten into a lock command, even when the agent had said the device was a switch. When no lock had that name, the closest-named lock was filled in. So "turn off the kitchen clock" unlocked the front door: with the Critical Action PIN on it was held, and entering the PIN unlocked the door; with no PIN set, the door unlocked at once. Turning on a scene named "Unlock" locked a door instead of activating the scene. Lock names in a non-Latin script were affected too: names were compared with every letter outside A to Z removed, so "Задняя дверь" (back door) and "Входная дверь" (front door) read as the same lock, and a request for one could unlock the other. A request is now treated as a lock command only when the agent says the device is a lock, or when Home Assistant finds the name belongs to locks and nothing else, matched the way Home Assistant matches it (any language, aliases included) among the devices exposed to Assist. A lock name that adds or leaves off a trailing "lock" ("Front Door" for "Front Door Lock", or the reverse) still finds the lock when exactly one lock answers to it, within the area or floor the request names. That lock is then named by its entity id, because its friendly name or an alias could also belong to another lock; the PIN prompt shows both, for example
unlock "Front Door Lock" (lock.front_door), as it does whenever a device is named by its entity id. A name that matches no lock, or more than one, is passed on as given, never redirected to another lock, and entering the PIN runs the request exactly as it was held: if that lock is removed in the meantime, the request fails rather than finding another lock. The same applies to alarm panels: a device with "alarm" or "security" in its name, such as a "Security Light", is no longer sent to the alarm tool, and a lock called "Security Door Lock" can be locked and unlocked by name again. A numeric code is taken as a sign the request was meant for the alarm panel only when the request names no device, or names only alarm panels; a code given for a lock (by its name, even a lock not exposed to Assist, its area or its entity id), or for a device Home Assistant cannot find, no longer sends the request to the alarm tool (#782). - The Critical Action PIN now checks what a script or scene does, not only the call that starts it (#775). A script run through its own tool, or a script or scene turned on by the agent, ran with no PIN even when it opened the garage door or unlocked the front door, unless a rule named that script or scene. A script is now held when one of its steps would be held in an automation, and a scene from Home Assistant's own scene config when an entity it sets would be: a scene that unlocks the front door asks for the PIN, a bedtime scene that locks it does not. A step that runs another script or scene, fires an event, or builds its action from a template is held, as in automations. A scene stored by another integration is held unless it comes from a lighting system (Hue, LIFX Cloud, LiteJet, Sunricher DALI), since a hub's scene (Fibaro, Vera, Overkiz, MQTT, KNX, deCONZ) can open a gate and a shade system's scene (Hunter Douglas PowerView) moves covers. A tool that calls services by name, such as an MCP service tool, is now checked the way an automation step is: a script or scene it runs is opened the same way, its targets are read the way Home Assistant reads them (
all, an area, a label, a group or a registry id is held when a rule applies to the call, and always when it could run a script or scene), and a call that runs other stored configuration, such asautomation.trigger, is held. On Home Assistant 2026.8, where a script's tool is named by the script alone, the script is recognized the same way, and a tool that only shares a script's name is still checked by the call it makes. The PIN prompt for a script names the script as Home Assistant knows it rather than repeating the agent's arguments. A rule naming a script now also covers running it through its own tool, and still matches after the script's entity is renamed. - An automation step that applies a scene with
scene.applyand gives the entities indata_templateinstead ofdatais now checked for the Critical Action PIN. Home Assistant uses thedata_templateentities, but onlydatawas read, so such a step could unlock a door with no PIN. Likewise, a step whosedataortargethas a templated key (which Home Assistant renders intoentitiesorentity_idwhen the step runs) is now treated as unreadable and held.