ci(triage): catch a malformed credential, not just a revoked one

The token was replaced at 08:25 and the runs at 08:26 still failed — with a
different error, which this gate did not recognise:

  "Invalid auth token · Fix external auth token · Invalid Authorization header
   value from CLAUDE_CODE_OAUTH_TOKEN: it contains a line break at character 62
   (110 characters on 2 lines)."

  "error": "invalid_request", "api_error_status": null

No "authentication_failed", no 401 — so the gate added a few hours earlier
reported this as a generic workflow fault, which is exactly the unhelpful
message it existed to replace. Two shapes of the same problem inside a week:
revoked (401) and malformed (invalid_request, reason only in the message text).

Detection now also matches the text marker, but only on an object the SDK
itself flagged with is_api_error_message — an issue body that merely mentions
the secret's name cannot fake one, and a false positive would change only the
message since this branch exits 1 regardless.

The SDK's own wording is more useful than anything inferred here ("a line break
at character 62" names the exact defect), so it is now quoted verbatim in the
annotation, and the remedy says to re-enter the secret as a SINGLE line.

Verified against both real execution-file shapes captured from production —
today's malformed failure and the 08-30 revoked one — plus regression that
max_turns still escalates, generic failures keep the generic message, and an
issue mentioning CLAUDE_CODE_OAUTH_TOKEN is not misreported as a credential
fault.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.github/workflows/daily_ai_fix.yaml

@@ -125,7 +125,7 @@ jobs:
 
       - name: Analyse and fix
         if: steps.batch.outputs.count != '0'
-        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # v1
+        uses: anthropics/claude-code-action@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Skip the OIDC -> Claude App token exchange. The scheduled path

.github/workflows/on_claude_mention.yml

@@ -64,7 +64,7 @@ jobs:
           fetch-depth: 1
 
       - name: Run Claude Code
-        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # v1
+        uses: anthropics/claude-code-action@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # AI_PR_TOKEN, not GITHUB_TOKEN, so a PR Claude opens triggers CI.

.github/workflows/on_issue_approved.yaml

@@ -135,7 +135,7 @@ jobs:
 
       - name: Execute the plan
         if: steps.bundle.outputs.has_plan == 'true'
-        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # v1
+        uses: anthropics/claude-code-action@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Skip the OIDC -> Claude App token exchange, which 401s whenever

.github/workflows/on_issues_ai_triage.yaml

@@ -166,7 +166,7 @@ jobs:
         id: classify
         if: github.event_name != 'issue_comment' || steps.claim.outputs.go == 'true'
         continue-on-error: true
-        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # v1
+        uses: anthropics/claude-code-action@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Without this the action falls back to the OIDC -> Claude App token
@@ -363,13 +363,22 @@ jobs:
           }
 
           # Did the run die because the Claude credential is bad? The action
-          # reports this uselessly — a revoked token surfaces as "--json-schema
-          # was provided but Claude did not return structured_output", which
-          # points at the schema and not at auth. The execution file carries the
-          # truth: api_retry / result objects with error "authentication_failed"
-          # and a 401. Same array guard and fail-closed posture as above; an
-          # unrecognised shape simply is not an auth failure and falls through
-          # to the generic branch.
+          # reports this uselessly — the failure surfaces as "--json-schema was
+          # provided but Claude did not return structured_output", which points
+          # at the schema and not at auth. The execution file carries the truth.
+          #
+          # A bad credential shows up in more than one shape, and both have been
+          # seen in production within a week:
+          #   * revoked token  -> error "authentication_failed", HTTP 401
+          #   * malformed token -> error "invalid_request", api_error_status
+          #     null, and the reason only in the SDK's message text ("Invalid
+          #     Authorization header value from CLAUDE_CODE_OAUTH_TOKEN: it
+          #     contains a line break at character 62").
+          # Matching only the first shape reported the second as a generic
+          # workflow fault, so the text marker is checked too — but only on an
+          # object the SDK itself flagged as an API error, so an issue body that
+          # merely mentions the secret's name cannot fake one. A false positive
+          # would change only the message: this branch exits 1 either way.
           hit_auth_failure() {
             [ -n "${EXECUTION_FILE:-}" ] && [ -s "${EXECUTION_FILE:-}" ] || return 1
             jq -e '(type == "array") and
@@ -377,10 +386,26 @@ jobs:
                        (type == "object") and
                        (((.error? // "") == "authentication_failed") or
                         ((.error_status? // 0) == 401) or
-                        ((.api_error_status? // 0) == 401)))' \
+                        ((.api_error_status? // 0) == 401) or
+                        (((.is_api_error_message? // false) == true) and
+                         (tostring | test("CLAUDE_CODE_OAUTH_TOKEN|Invalid auth token")))))' \
                "$EXECUTION_FILE" >/dev/null 2>&1
           }
 
+          # The SDK's own words are far more useful than anything this script
+          # can infer — "it contains a line break at character 62" names the
+          # exact defect. Surface it verbatim when present.
+          auth_failure_detail() {
+            [ -n "${EXECUTION_FILE:-}" ] && [ -s "${EXECUTION_FILE:-}" ] || return 0
+            jq -r 'if type == "array" then
+                     [ .[]? | select(type == "object")
+                            | select((.is_api_error_message? // false) == true)
+                            | tostring
+                            | capture("(?<m>Invalid Authorization header value[^\"]*|Invalid auth token[^\"]*)")
+                            | .m ] | first // ""
+                   else "" end' "$EXECUTION_FILE" 2> /dev/null || true
+          }
+
           # GATE 1 — did the action itself run? This is checked BEFORE looking
           # at the payload, because the action can fail *after* having written
           # a valid structured output: the object would sail through the shape
@@ -405,7 +430,8 @@ jobs:
             # goes quiet while each run still fails in a way that reads like a
             # per-issue problem. Say plainly what is wrong and what to do.
             if hit_auth_failure; then
-              echo "::error::CLAUDE_CODE_OAUTH_TOKEN is rejected (HTTP 401 / authentication_failed). This is NOT a problem with issue #$ISSUE — every AI workflow is down until the credential is replaced. Regenerate it with 'claude setup-token' and update the CLAUDE_CODE_OAUTH_TOKEN secret in the CR_PAT environment. Set the AI_DISABLED repo variable to 'true' to silence these runs meanwhile."
+              DETAIL=$(auth_failure_detail)
+              echo "::error::CLAUDE_CODE_OAUTH_TOKEN is being rejected${DETAIL:+ — $DETAIL}. This is NOT a problem with issue #$ISSUE: every AI workflow is down until the credential is fixed. Regenerate with 'claude setup-token' and re-enter the secret in the CR_PAT environment as a SINGLE line with no line break or trailing newline. Set the AI_DISABLED repo variable to 'true' to silence these runs meanwhile."
               exit 1
             fi
 

.github/workflows/on_pr_coderabbit.yml

@@ -79,7 +79,7 @@ jobs:
 
       - name: Address CodeRabbit comments
         if: steps.claim.outputs.go == 'true'
-        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # v1
+        uses: anthropics/claude-code-action@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Skip the OIDC -> Claude App token exchange, which 401s whenever

baikal/CHANGELOG.md

@@ -1,10 +1,3 @@
-## 0.12.1 (2026-09-03)
-
-- Update to Baikal 0.12.1 from 0.10.1 (changelog : <https://github.com/sabre-io/Baikal/releases>). This includes the 0.12.1 fix for an XSS vulnerability that let an authenticated user take over the admin interface by renaming a calendar
-- ⚠ After the update, open the Baikal web admin once : Baikal asks to confirm the upgrade before it serves calendars again
-- The application is now taken from the release published by sabre-io instead of from the ckulka/baikal-docker image, which stopped at 0.10.1. The base image still provides nginx, php-fpm and msmtp. Automatic version tracking is enabled again, following sabre-io/Baikal
-- The Baikal application files in the addon data folder are now replaced on every start instead of being kept. Calendars, contacts, users and the Baikal configuration are untouched ; any manual edit made inside the application folders themselves is lost
-
 - The Home Assistant project has deprecated support for the armv7, armhf and i386 architectures. Support wil be fully dropped in the upcoming Home Assistant 2025.12 release
 
 ## 0.10.1-hafix4 (2025-11-18)

baikal/Dockerfile

@@ -16,19 +16,7 @@
 
 ARG BUILD_FROM
 ARG BUILD_VERSION
-ARG BUILD_UPSTREAM="0.12.1"
-
-# ckulka/baikal-docker, which builds the base image, stopped publishing new
-# Baikal versions at 0.10.1 : the base image is used for its runtime only
-# (nginx, php-fpm, msmtp) and the application comes from the release published
-# by sabre-io itself
-FROM alpine:3.21 AS baikal
-ARG BUILD_UPSTREAM
-RUN apk add --no-cache curl unzip \
-    && curl -f -s -S -L -o /tmp/baikal.zip "https://github.com/sabre-io/Baikal/releases/download/${BUILD_UPSTREAM}/baikal-${BUILD_UPSTREAM}.zip" \
-    && unzip -q /tmp/baikal.zip -d / \
-    && rm /tmp/baikal.zip
-
+ARG BUILD_UPSTREAM="0.10.1+hafix"
 FROM ${BUILD_FROM}
 
 ##################
@@ -40,24 +28,6 @@ ENV S6_CMD_WAIT_FOR_SERVICES=1 \
     S6_CMD_WAIT_FOR_SERVICES_MAXTIME=0 \
     S6_SERVICES_GRACETIME=0
 
-# Ship the Baikal release instead of the one bundled in the base image
-RUN rm -rf /var/www/baikal
-COPY --from=baikal --chown=nginx:nginx /baikal /var/www/baikal
-
-# Home Assistant asks for an expanded time range, and Baikal stores
-# cal:calendar-timezone as a bare timezone name rather than as the VTIMEZONE
-# object sabre/dav expects, so sabre/dav raises a ParseException and answers
-# 500 (sabre-io/Baikal#1241 and sabre-io/dav#1318, both still open). Read the
-# value as a timezone name instead. The two checks turn a release that moved
-# this code into a failed build rather than into an addon that Home Assistant
-# cannot read.
-# hadolint ignore=SC2016
-RUN \
-    DAVPLUGIN="/var/www/baikal/vendor/sabre/dav/lib/CalDAV/Plugin.php" \
-    && sed -i '/^                \/\/ This property contains a VCALENDAR with a single$/,/^                \$vtimezoneObj->destroy();$/c\                $calendarTimeZone = new DateTimeZone($tzResult[$tzProp]);' "$DAVPLUGIN" \
-    && grep -qxF '                $calendarTimeZone = new DateTimeZone($tzResult[$tzProp]);' "$DAVPLUGIN" \
-    && ! grep -qxF '                $calendarTimeZone = $vtimezoneObj->VTIMEZONE->getTimeZone();' "$DAVPLUGIN"
-
 # Image specific modifications
 # hadolint ignore=SC2015, SC2013, SC2086
 RUN \

baikal/README.md

@@ -33,9 +33,7 @@ _Thanks to everyone having starred my repo! To star it click on the image below,
 ---
 
 [Baikal](https://sabre.io/baikal/) is a lightweight CalDAV+CardDAV server. It offers an extensive web interface with easy management of users, address books and calendars. It is fast and simple to install and only needs a basic php capable server. The data can be stored in a MySQL or a SQLite database.
-It ships the release published by [sabre-io](https://github.com/sabre-io/Baikal/releases), running on the nginx and php-fpm image built by <https://github.com/ckulka/baikal-docker>.
-
-After an update of Baikal itself, open the web admin once : Baikal asks to confirm the upgrade before it serves calendars again. Calendars, contacts, users and the Baikal configuration are kept, but a manual edit made inside the application folders themselves is replaced on every start.
+It is based on the docker image : https://github.com/ckulka/baikal-docker
 
 ## Configuration
 

baikal/build.json

@@ -1,6 +1,6 @@
 {
     "build_from": {
-        "aarch64": "ckulka/baikal:nginx-php8.2",
-        "amd64": "ckulka/baikal:nginx-php8.2"
+        "aarch64": "ghcr.io/mralucarddante/baikal-docker-hass:latest",
+        "amd64": "ghcr.io/mralucarddante/baikal-docker-hass:latest"
     }
 }

baikal/config.yaml

@@ -84,5 +84,5 @@ schema:
 slug: baikal
 udev: true
 url: https://github.com/alexbelgium/hassio-addons
-version: "0.12.1"
+version: 0.10.1-hafix4
 webui: "[PROTO:ssl]://[HOST]:[PORT:80]"

baikal/rootfs/etc/cont-init.d/90-run.sh

@@ -1,21 +1,7 @@
 #!/bin/bash
-set -e
 
-# Baikal keeps its database in Specific and its configuration in config. The
-# release ships both as empty folders, so they are created here rather than
-# copied, and are then left alone : they hold the user's data
-mkdir -p /data/config /data/Specific/db
-
-# Everything else is application code, and is replaced on every start so that a
-# rebuilt image actually replaces the code that is served
-for item in /var/www/baikal/*; do
-    name="$(basename "$item")"
-    case "$name" in
-        Specific | config) continue ;;
-    esac
-    rm -rf "/data/$name"
-    cp -rf "$item" /data/
-done
+# Copy data
+cp -rnf /var/www/baikal/* /data/
 
 # Fix permissions
 chown -R nginx:nginx /data

baikal/updater.json

@@ -1,9 +1,9 @@
 {
-  "github_beta": "false",
-  "last_update": "2026-09-03",
+  "github_exclude": "+",
+  "last_update": "26-04-2025",
   "repository": "alexbelgium/hassio-addons",
   "slug": "baikal",
   "source": "github",
-  "upstream_repo": "sabre-io/Baikal",
-  "upstream_version": "0.12.1"
+  "upstream_repo": "ckulka/baikal-docker",
+  "upstream_version": "0.10.1"
 }

birdnet-go-dev/CHANGELOG.md

@@ -1,13 +1,3 @@
-## 20260901.4 (01-09-2026)
-- Minor bugs fixed
-## 20260901.3 (01-09-2026)
-- Rebuild: live spectrogram in Currently Hearing now uses the same SoX recipe, palette and 2:1 ratio as the detection spectrograms, with a kHz axis overlay (fork PR #61)
-## 20260901.2 (01-09-2026)
-- Rebuild: re-merges the open fork PRs, adding a static SoX spectrogram of the chunk being analysed to the Currently Hearing card (fork PR #61)
-## 20260901.1 (01-09-2026)
-- Minor bugs fixed
-## 20260901 (01-09-2026)
-- Synced with upstream birdnet-go (7 commits, incl. Go 1.27 upgrade); build image bumped to golang:1.27-trixie to match; resolved merge conflict in fork PR #6
 ## 20260829.2 (29-08-2026)
 - Minor bugs fixed
 ## 20260829.1 (29-08-2026)

birdnet-go-dev/Dockerfile

@@ -89,7 +89,7 @@ RUN apk add --no-cache curl && \
 # 1a Build environment (mirrors tphakala/birdnet-go Docker/Dockerfile)  #
 #########################################################################
 
-FROM --platform=$BUILDPLATFORM golang:1.27-trixie AS buildenv
+FROM --platform=$BUILDPLATFORM golang:1.26-trixie AS buildenv
 ARG BUILD_VERSION
 ENV BUILD_VERSION=${BUILD_VERSION:-unknown}
 

birdnet-go-dev/config.yaml

@@ -127,5 +127,5 @@ slug: birdnet-go-dev
 udev: true
 url: https://github.com/alexbelgium/hassio-addons
 usb: true
-version: "20260901.4"
+version: "20260829.2"
 video: true

calibre_web/CHANGELOG.md

@@ -1,8 +1,4 @@
  
-## 0.6.27.4 (2026-09-03)
-- Fix: Kobo sync could not be enabled, failing with "Kepubify binary not found" even when the path was set to `/usr/bin` by hand. The LinuxServer base image downloads `/usr/bin/kepubify` with `curl -o` and never marks it executable (mode 0644), and calibre-web only accepts a binary that passes `os.access(X_OK)`. The addon now sets mode 0755 on it at build time (https://github.com/alexbelgium/hassio-addons/issues/3040)
-- Fix: calibre-web only looks for kepubify under `/opt/kepubify`, never `/usr/bin` where the base image puts it, so the kepubify path was stored empty on the first start and never retried. The addon now fills it in with `/usr/bin` when it is still empty, leaving a path set by hand untouched. On a brand new install `/config/app.db` does not exist yet during the first start, so the path is filled in on the second start, as is already the case for the ingress settings
-
 ## 0.6.27.3 (2026-08-30)
 - Doc: explain in the README that Calibre-Web's optional extras (metadata, kobo, gdrive, gmail, goodreads, ldap, oauth, comics) are already installed by the LinuxServer base image, that `pip install calibreweb[...]` inside the container is useless and not persistent, and that the cover fields on the Edit Metadata page are gated on `Enable Uploads` plus the user's `Upload` permission (https://github.com/alexbelgium/hassio-addons/issues/1143)
 - Fix: remove the Dockerfile step that claimed to install the Calibre binaries into `/opt/calibre`. There is no `wget` in the image, so the command failed silently and left the layer empty; the binaries are and were provided at start by the default `linuxserver/mods:universal-calibre` docker mod

calibre_web/Dockerfile

@@ -45,13 +45,8 @@ ARG CONFIGLOCATION="/config"
 RUN chmod 744 /ha_lsio.sh && if grep -qr "lsio" /etc; then /ha_lsio.sh "$CONFIGLOCATION"; fi && rm /ha_lsio.sh
 
 # Specific images modifications
-# The base image installs kepubify with "curl -o /usr/bin/kepubify" and never marks it executable,
-# so calibre-web's resolve_binary_path() rejects it (it requires os.access(X_OK)) and enabling
-# Kobo sync fails with "Kepubify binary not found". Unguarded on purpose: if a future base image
-# stops shipping the binary, the build must fail here rather than ship a silently broken add-on.
 RUN \
-    usermod --home /config abc \
-    && chmod 0755 /usr/bin/kepubify
+    usermod --home /config abc
 
 ##################
 # 3 Install apps #

calibre_web/config.yaml

@@ -116,5 +116,5 @@ schema:
 slug: calibre-web
 udev: true
 url: https://github.com/alexbelgium/hassio-addons/tree/master/calibre_web
-version: "0.6.27.4"
+version: "0.6.27.3"
 video: true

calibre_web/rootfs/etc/cont-init.d/80-configuration.sh

@@ -32,13 +32,6 @@ else
     # before calibre-web, so a failure here is not fatal : the next start applies it.
     trusted_ips_error=$(sqlite3 /config/app.db "update settings set config_reverse_proxy_trusted_ips='127.0.0.1,::1,::ffff:127.0.0.1,172.30.32.0/23,::ffff:172.30.32.0/119,'||coalesce(config_reverse_proxy_trusted_ips,'') where coalesce(config_reverse_proxy_trusted_ips,'') not like '%::ffff:172.30.32.0/119%'" 2>&1) ||
         bashio::log.warning "Could not set the ingress trusted ip list, it will be applied at next start (${trusted_ips_error})"
-
-    # Calibre-web only autodetects kepubify under /opt/kepubify, never /usr/bin where the base
-    # image puts it, so the setting is stored empty on the very first start and is never retried
-    # afterwards : every install ends up with an empty path and Kobo sync cannot be enabled.
-    # Filled in only when it is still empty, so a path the user set by hand is never overwritten.
-    kepubify_error=$(sqlite3 /config/app.db "update settings set config_kepubifypath='/usr/bin' where coalesce(config_kepubifypath,'') = ''" 2>&1) ||
-        bashio::log.warning "Could not set the kepubify path, it will be applied at next start (${kepubify_error})"
 fi
 
 bashio::log.info "Default username:password is admin:admin123"

filebrowser_quantum/CHANGELOG.md

@@ -1,18 +1,4 @@
  
-## 1.5.3.3 (2026-08-31)
-- Complete the iOS companion app fix from 1.5.3.2. The "no preview available"
-  screen -- what you get for a `.zip`, `.bin` or anything else FileBrowser
-  cannot render -- offers its Download and "Open file" buttons as new-tab
-  links, and so does the share list in settings. The app hands every new tab
-  to an external browser, which carries no ingress session, so those answered
-  401. Those two buttons and the settings share links now stay in the panel
-  when running in the companion app, and open a new tab as before in a normal
-  browser -- as does a cmd/ctrl/shift-click anywhere, which is left alone.
-  Download also saves the file instead of displaying it, which 1.5.3.2 only
-  fixed for the download button in the file list. Links the app opens without
-  a link element, such as the public-share sidebar download, are still
-  affected.
- 
 ## 1.5.3.2 (2026-08-30)
 - Fix Download in the Home Assistant iOS companion app (iOS 17 and later),
   where a file opened and showed its content with no way to save it.

filebrowser_quantum/config.yaml

@@ -118,4 +118,4 @@ schema:
 slug: filebrowser_quantum
 udev: true
 url: https://github.com/alexbelgium/hassio-addons
-version: "1.5.3.3"
+version: "1.5.3.2"

filebrowser_quantum/rootfs/etc/nginx/servers/ingress.conf

@@ -41,72 +41,31 @@ server {
        # same instance's files/ or public/share/ route. Same shape as the komga
        # add-on's ingress filter.
        #
-       # 2. Saving and opening a file. FileBrowser downloads by clicking an <a>
-       # that carries no download attribute -- a hidden one it builds itself
-       # (api/resources.js), and two visible ones in the "no preview available"
-       # fallback (views/files/Preview.vue), which are also target="_blank".
-       # Neither works in the Home Assistant companion app:
+       # 2. Download. FileBrowser downloads a file by building an <a> with no
+       # download attribute, clicking it, and letting the attachment response do
+       # the rest. The Home Assistant iOS companion app is a WKWebView, and a
+       # download happens there only when WebKit turns a navigation *action*
+       # into a WKDownload, which is what the download attribute does -- the app
+       # hands that to its own download manager
+       # (WebViewController+WebKitDelegates.swift, navigationAction:didBecome
+       # download:). Its response policy delegate returns .allow for every
+       # sub-frame and never returns .download, so a plain attachment navigation
+       # inside the ingress panel is just rendered: a text file opens and shows
+       # its content with no way to save it. Adding the attribute makes the same
+       # click a real download. Desktop browsers already downloaded these and
+       # are unaffected, and an empty value keeps the filename the server sends
+       # in Content-Disposition. Matched on the two exact download endpoints,
+       # minus inline=true: the "no preview available" fallback renders an
+       # "Open file" link on the same endpoint with that parameter
+       # (views/files/Preview.vue), and it is meant to open, not save. Only
+       # programmatic clicks pass through here -- a person clicking a link never
+       # calls HTMLAnchorElement.prototype.click -- so this reaches
+       # FileBrowser's own hidden download anchor and nothing a user clicks.
        #
-       #   - A download happens in its WKWebView only when WebKit turns a
-       #     navigation *action* into a WKDownload, which is what the download
-       #     attribute does; the app hands that to its own download manager
-       #     (WebViewController+WebKitDelegates.swift, navigationAction:didBecome
-       #     download:, iOS 17+). Its response policy delegate returns .allow for
-       #     every sub-frame and never returns .download, so a plain attachment
-       #     navigation in the ingress panel is just rendered: the file opens and
-       #     shows its content with no way to save it.
-       #   - target="_blank" is worse. The app has no navigationAction policy
-       #     delegate, so every new-window request reaches createWebViewWith,
-       #     which hands the url to an external browser. That browser carries no
-       #     ingress session cookie, so Home Assistant answers 401.
-       #
-       # One capturing click listener covers both, and covers the hidden anchor
-       # too: a programmatic .click() on an anchor that is in the document
-       # dispatches through it exactly like a real one -- same event, button 0,
-       # no modifiers -- and the capture phase runs before the link is followed.
-       # It replaces an earlier wrapper around HTMLAnchorElement.prototype.click,
-       # which reached the hidden anchor but not the two the user clicks. The
-       # wrapper would also have caught a click on a *detached* anchor, which
-       # this cannot; both of FileBrowser's download paths append theirs to the
-       # body first (api/resources.js), so nothing is lost today.
-       #
-       # Only unmodified primary clicks are touched. A cmd/ctrl/shift-click is
-       # an explicit request for a separate context and is left alone, which
-       # matters on desktop and in the Mac Catalyst app.
-       #
-       # Downloads gain the attribute everywhere -- desktop browsers already
-       # saved these on a plain click, and an empty value keeps the filename the
-       # server sends in Content-Disposition. One behaviour does change there:
-       # if the endpoint answers with an error the body is saved as a file
-       # instead of being shown, because the decision is made before the
-       # response exists. Matched on the two exact download endpoints minus
-       # inline=true, which is the fallback's "Open file" link and is meant to
-       # open rather than save. That branch drops target="_blank" in every
-       # browser too: with the attribute present a same-origin link downloads
-       # and never opens a tab (measured), so it changes nothing here, but it
-       # stops the companion app from taking its new-window path before it
-       # considers the download -- an ordering that cannot be tested from
-       # outside iOS.
-       #
-       # Dropping target="_blank" from links that are *not* downloads is limited
-       # to the companion app, identified by the Mobile/HomeAssistant marker it
-       # appends to the user agent
-       # (HAAPI.swift, applicationNameForUserAgent -- it covers iPhone, iPad and
-       # Mac Catalyst). In a real browser a new tab is the better behaviour and
-       # is left alone; in the app it is a 401. It applies to any same-origin
-       # link below the add-on's own base path, which in practice is the
-       # "Open file" button and the share links in settings
-       # (views/settings/Shares.vue). Links to other origins keep their new tab,
-       # and only an exact target="_blank" is matched, so named windows, _parent
-       # and _top are untouched.
-       #
-       # Not covered, and still 401 in the app: anything the app opens with
-       # window.open() rather than an anchor, which is the public-share sidebar
-       # download and absolute sidebar links (components/sidebar/Links.vue); and
-       # links inside a document FileBrowser renders in its own iframe -- the
-       # pdf viewer, the srcdoc markdown/html preview, OnlyOffice -- because a
-       # listener on this document never sees another document's clicks.
-       sub_filter "window.__pwaDeferredPrompt = null;" "window.__pwaDeferredPrompt = null;(function(){var o=window.open;window.open=function(u,n,f){try{var b=(window.globalVars||{}).baseURL;if(u&&n==='_blank'&&!f&&b){if(b.slice(-1)!=='/')b+='/';var t=new URL(u,location.href);if((t.protocol==='http:'||t.protocol==='https:')&&t.origin===location.origin&&(t.pathname.indexOf(b+'files/')===0||t.pathname.indexOf(b+'public/share/')===0)){location.assign(t.href);return window}}}catch(e){}return o.apply(window,arguments)};document.addEventListener('click',function(e){try{if(e.button||e.metaKey||e.ctrlKey||e.shiftKey||e.altKey)return;var a=e.target&&e.target.closest?e.target.closest('a'):null;if(!a||!a.href)return;var b=(window.globalVars||{}).baseURL;if(!b)return;if(b.slice(-1)!=='/')b+='/';var t=new URL(a.href,location.href);if(t.origin!==location.origin)return;if(!a.hasAttribute('download')&&t.searchParams.get('inline')!=='true'&&(t.pathname===b+'api/resources/download'||t.pathname===b+'public/api/resources/download')){a.download='';a.removeAttribute('target');return}if(a.target==='_blank'&&t.pathname.indexOf(b)===0&&navigator.userAgent.indexOf('Mobile/HomeAssistant')!==-1){a.removeAttribute('target')}}catch(err){}},true)})();";
+       # Not covered: the public-share sidebar downloads with window.open()
+       # rather than an anchor, and the app's download manager is gated on
+       # iOS 17 (WebViewController+WebKitDelegates.swift).
+       sub_filter "window.__pwaDeferredPrompt = null;" "window.__pwaDeferredPrompt = null;(function(){var o=window.open;window.open=function(u,n,f){try{var b=(window.globalVars||{}).baseURL;if(u&&n==='_blank'&&!f&&b){if(b.slice(-1)!=='/')b+='/';var t=new URL(u,location.href);if((t.protocol==='http:'||t.protocol==='https:')&&t.origin===location.origin&&(t.pathname.indexOf(b+'files/')===0||t.pathname.indexOf(b+'public/share/')===0)){location.assign(t.href);return window}}}catch(e){}return o.apply(window,arguments)};var c=HTMLAnchorElement.prototype.click;HTMLAnchorElement.prototype.click=function(){try{var b=(window.globalVars||{}).baseURL;if(b&&this.href&&!this.hasAttribute('download')){if(b.slice(-1)!=='/')b+='/';var t=new URL(this.href,location.href);if(t.origin===location.origin&&t.searchParams.get('inline')!=='true'&&(t.pathname===b+'api/resources/download'||t.pathname===b+'public/api/resources/download')){this.download=''}}}catch(e){}return c.apply(this,arguments)}})();";
   }
 
 }