v2.1.0-beta.2

Security

• Tool calls now execute as the token's owner, not a substituted admin.
  Previously every WebSocket-backed call ran as the first active admin
  (admins[0]), so any valid bearer token gained admin rights. Calls now run
  as the Home Assistant user who owns the token, and HA's own permission
  machinery enforces that user's rights. Mutating operations fail closed
  when no authenticated user is present. ha_auth now acts on the calling
  token's own user (it too previously used admins[0], letting any token mint
  an admin long-lived token).
• Admin-only operations now require an admin token. Tools that mutate via
  direct HA APIs with no per-user check of their own — ha_registry,
  ha_config_entries, ha_config_flow, ha_energy, ha_statistics,
  ha_set_state, ha_delete_state, ha_yaml_config, ha_blueprint,
  ha_recorder, ha_system, ha_hacs — now require the token's user to be an
  administrator (matching Home Assistant's own policy for those operations).
  Their read ops remain available to any token. In particular ha_yaml_config
  (automation/script authoring) and ha_hacs op=download (installs code) were
  previously reachable by any write-enabled token.
• ha_blueprint now rejects unsafe paths for both op=import (filename)
  and op=delete (path) — path separators that escape, .. segments, and
  non-.yaml targets. Home Assistant's async_remove_blueprint performs an
  unsanitized path join + unlink, so op=delete was an arbitrary-file-delete
  vector; the guard closes it.
• ha_hacs op=download (installs integration code) is now classed destructive
  (default off) rather than a plain write.
• Rate limiter now counts JSON-RPC batches. A batch of N messages costs N
  slots and batches are capped (100), so a single request can no longer bypass
  the per-minute limit.
• The endpoint fails closed when the integration is unloaded. Previously the
  aiohttp view kept serving after unload and fell back to permissive option
  defaults (re-enabling writes); it now rejects requests until the entry is
  loaded again.
• Destructive/write ops are now gated per op. Several meta-tools
  (ha_registry, ha_config_entries, ha_blueprint, ha_energy,
  ha_statistics, ha_helper, ha_backup, ha_yaml_config) previously
  declared their gating only in prose or a coarse whole-tool flag, so
  create/update/delete/purge/restore could run with allow_destructive (or
  even allow_write) disabled. Gating is now declarative and enforced
  centrally before the handler runs.

Changed

• Destructive ops (delete / remove / purge / revoke / restore /
  clear) now require allow_destructive (default off) rather than
  running under allow_write. Workflows that relied on the old behavior must
  enable the toggle.
• Meta-tool permission gating moved from whole-tool requires_* flags to
  declarative per-op write_ops / destructive_ops. This also fixes
  over-gating: ha_recorder op=info and ha_hacs read ops no longer
  require a write/destructive toggle and reappear in the default tool list.