fix(calibre-web): make kepubify executable so Kobo sync can be enabled

The LinuxServer base image installs kepubify with `curl -o /usr/bin/kepubify`
and never marks it executable, so the file ships as mode 0644. Calibre-web's
resolve_binary_path() only accepts a binary that passes os.access(X_OK), so
enabling Kobo sync failed with "Kepubify binary not found" even when the path
was set to /usr/bin by hand. Verified against the published layer of
lscr.io/linuxserver/calibre-web:arm64v8-latest, whose tar header for
usr/bin/kepubify reads `-rw-r--r-- 0/0 3670016`.

Set mode 0755 on it at build time, unguarded: if a future base image stops
shipping the binary, the build should fail rather than ship a broken add-on.

Calibre-web separately only autodetects kepubify under /opt/kepubify, never
/usr/bin, so the setting was stored empty on the first start and never
retried. Fill it in with /usr/bin from the cont-init script that already
applies conditional settings to app.db, and only while it is still empty, so
a path the user set by hand is never overwritten.

Fixes https://github.com/alexbelgium/hassio-addons/issues/3040

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@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
+        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # 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@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
+        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # 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@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
+        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # 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@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
+        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Without this the action falls back to the OIDC -> Claude App token
@@ -363,22 +363,13 @@ jobs:
           }
 
           # Did the run die because the Claude credential is bad? The action
-          # 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.
+          # 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.
           hit_auth_failure() {
             [ -n "${EXECUTION_FILE:-}" ] && [ -s "${EXECUTION_FILE:-}" ] || return 1
             jq -e '(type == "array") and
@@ -386,26 +377,10 @@ jobs:
                        (type == "object") and
                        (((.error? // "") == "authentication_failed") or
                         ((.error_status? // 0) == 401) or
-                        ((.api_error_status? // 0) == 401) or
-                        (((.is_api_error_message? // false) == true) and
-                         (tostring | test("CLAUDE_CODE_OAUTH_TOKEN|Invalid auth token")))))' \
+                        ((.api_error_status? // 0) == 401)))' \
                "$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
@@ -430,8 +405,7 @@ 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
-              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."
+              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."
               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@dcb57747bfceeaa1fa72638cae52295d1d853d4a  # v1
+        uses: anthropics/claude-code-action@a874e9ecd7bb36efdad65429c6b35815f5a08f10  # 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,3 +1,10 @@
+## 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,7 +16,19 @@
 
 ARG BUILD_FROM
 ARG BUILD_VERSION
-ARG BUILD_UPSTREAM="0.10.1+hafix"
+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
+
 FROM ${BUILD_FROM}
 
 ##################
@@ -28,6 +40,24 @@ 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,7 +33,9 @@ _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 is based on the docker image : https://github.com/ckulka/baikal-docker
+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.
 
 ## Configuration
 

baikal/build.json

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

baikal/config.yaml

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

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

@@ -1,7 +1,21 @@
 #!/bin/bash
+set -e
 
-# Copy data
-cp -rnf /var/www/baikal/* /data/
+# 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
 
 # Fix permissions
 chown -R nginx:nginx /data

baikal/updater.json

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

birdnet-go-dev/CHANGELOG.md

@@ -1,3 +1,13 @@
+## 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.26-trixie AS buildenv
+FROM --platform=$BUILDPLATFORM golang:1.27-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: "20260829.2"
+version: "20260901.4"
 video: true

calibre_web/CHANGELOG.md

@@ -1,4 +1,8 @@
  
+## 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,8 +45,13 @@ 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
+    usermod --home /config abc \
+    && chmod 0755 /usr/bin/kepubify
 
 ##################
 # 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.3"
+version: "0.6.27.4"
 video: true

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

@@ -32,6 +32,13 @@ 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,4 +1,18 @@
  
+## 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.2"
+version: "1.5.3.3"

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

@@ -41,31 +41,72 @@ server {
        # same instance's files/ or public/share/ route. Same shape as the komga
        # add-on's ingress filter.
        #
-       # 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.
+       # 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:
        #
-       # 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)}})();";
+       #   - 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)})();";
   }
 
 }