GitHub bot: changelog [nobuild]

Added a breaking change note for admin ingress visibility.

.claude/skills/hassio-addon-workflow/SKILL.md

@@ -4,29 +4,30 @@ description: >-
   Workflow for alexbelgium/hassio-addons Home Assistant add-on work: diagnose with real
   measurements, independent Codex review, implement, open a PR, resolve CodeRabbit / Copilot /
   Codex bot review comments, verify in production. Use for any task touching an add-on in this
-  repo — bugs, RAM/CPU/performance tuning, Dockerfile, config.yaml, cont-init.d or s6 changes,
-  version bumps, opening or iterating PRs — and when asked to "check with codex", "verify with
-  chatgpt", or resolve bot comments. Cheap for small asks: a light path skips the heavy steps.
+  repo — bugs, RAM/CPU/performance tuning, Dockerfile, config.yaml, build.json,
+  updater.json, cont-init.d, services.d or s6 changes, version and CHANGELOG bumps, a failing
+  add-on CI check, opening or iterating PRs — and, on an add-on task, when asked to "check with
+  codex", "verify with chatgpt", or resolve bot comments. Cheap for small asks: a light path skips
+  the heavy steps.
 ---
 
 # Home Assistant add-on workflow
 
-**Answer style.** Chat replies are terse: no pleasantries, no tool-call narration, no decorative
-tables or emoji, no dumped logs — quote the shortest decisive line, and don't re-read or re-print
-what is already in context. Fragments and dropped articles are fine. Never compressed: uncertainty
-markers ("likely", "assumed", "not verified"), negations (`not`/`never`/`no`/`only`), numbers,
-units, technical terms, code blocks, error strings — step 9's Verified/Checked/Assumed distinction
-outranks brevity every time. Write in full prose, not fragments, for security warnings,
-irreversible-action confirmations, and any multi-step sequence a fragment could make ambiguous.
-Persisted text is prose too: commits, CHANGELOG entries, PR bodies, review-thread replies, the
-step 10 report.
+**Answer style.** Chat replies are terse — no pleasantries, tool-call narration, decorative tables,
+emoji or dumped logs; quote the shortest decisive line and don't re-print what is already in
+context. Telegraphic fragments are fine *there*. Two things outrank brevity, because dropping a
+word from either changes the meaning rather than shortening it: never compress uncertainty markers
+("likely", "assumed", "not verified"), negations, numbers, units, technical terms, code or error
+strings — step 9's Verified/Checked/Assumed distinction wins every time; and write full prose
+wherever a fragment could be read two ways — security warnings, irreversible-action confirmations,
+multi-step sequences, and everything persisted (commits, CHANGELOG entries, PR bodies, review-thread
+replies, the step 10 report).
 
 Triage first, then one of two paths:
 
 - **Light** — typo/doc fixes, CHANGELOG edits, version bumps, one-file edits at ladder levels
-  1-3 (below), simple questions: scope → implement → validate (`$SKILL/scripts/validate.sh
-  <addon> --vs-master`; `$SKILL` defined below) → PR (version bump + CHANGELOG still required) →
-  resolve bot comments.
+  1-3 (below), simple questions: scope → implement → validate (step 4) → PR (version bump +
+  CHANGELOG still required) → resolve bot comments.
 - **Full loop** — performance/RAM/CPU work, diagnosis, anything changing a shipped default,
   ladder levels 4-6, or an explicit Codex-check request: scope → measure → plan → Codex reviews
   the plan → implement → simplify → Codex reviews the code → **simplify again** → PR → resolve
@@ -47,9 +48,8 @@ reasoning about a hypothetical *host* either. A defensive branch is complexity l
 the input that reaches it and the image or host where that happens, or delete it and let the case
 fail visibly instead.
 
-**Repo layout.** `alexbelgium/hassio-addons`; each add-on is a top-level directory. This skill is
-checked in at `.claude/skills/hassio-addon-workflow/` (canonical copy). Set the skill root once,
-then every `scripts/…` and `references/…` path below is relative to it:
+**Skill root.** The canonical copy lives at `.claude/skills/hassio-addon-workflow/`. Set it once;
+every `scripts/…` and `references/…` path below is relative to it:
 
 ```bash
 SKILL="$(git rev-parse --show-toplevel)/.claude/skills/hassio-addon-workflow"
@@ -63,9 +63,10 @@ bash "$SKILL/scripts/preflight.sh"        # and likewise for the other scripts
 
 **Delegate heavy output to a subagent.** Codex reviews and multi-thread PR triage produce output
 you don't need verbatim in your own context. For Codex's plan review (step 3), Codex's code
-review (step 6), and PR-comment listing when there are more than ~5 threads (step 8): launch a
-subagent to run the command and report back only the objections/findings and your assessment of
-each, not the raw transcript.
+review (step 6), and PR-comment listing when there are more than ~5 threads (step 8): if subagents
+are available, launch one to run the command and report back only the objections/findings and your
+assessment of each, not the raw transcript. Otherwise redirect the output to a file and read the
+parts you need.
 
 ---
 
@@ -85,9 +86,11 @@ Measure the running add-on rather than reasoning from source (`$BUILD_VERSION` s
 - Is this flag/driver/package actually present? → inspect the artifact: `/proc/<pid>/cmdline`,
   `command -v`, `/var/log/apt/history.log`
 
-Verify you're reading the right revision first — `scripts/preflight.sh` catches a stale branch
-before it costs a full analysis pass. Measurement methodology, gotchas, and real failure examples:
-`references/evidence.md`.
+Verify you're reading the right revision first — `scripts/preflight.sh` compares the checkout
+against the running `$BUILD_VERSION`, which catches the usual stale branch before it costs a full
+analysis pass (a version match does not prove the source is identical). Read
+`references/evidence.md` before interpreting any number you did not get straight from
+`measure.sh`, and for the failure modes this step exists to prevent.
 
 ## 3. Plan — choose the mechanism level, then Codex reviews it (full loop)
 
@@ -117,45 +120,60 @@ Attack your own plan before implementing:
 - What am I **inferring** that I could instead **detect at runtime** or **record explicitly**?
   Highest-yield question here — see `references/evidence.md`'s failure-mode section.
 - For every branch that exists **only to survive something going wrong**: name the image or host
-  where that input actually arrives, and go and look. Naming is the bar, not reproducing it here —
-  `references/simplify.md` works the `/dev/shm` guard and the `s6-dumpenv` fallback through that
-  distinction.
+  where that input arrives (the standing rule above) and go and look, before you write it.
 
-Full loop only, before writing code: get Codex's independent read on the plan. Spawn a subagent
-whose prompt includes the path `references/codex-review.md` and tells it to follow that file's
-invocation, then report back only Codex's objections and an assessment of each — not the raw
-transcript.
+Full loop only, before writing code: get Codex's independent read on the plan, delegated as above —
+`references/codex-review.md` has the invocation and how to write the prompt.
 
 ## 4. Implement
 
-Touching a shell script, Dockerfile, or env option? Read `references/traps.md` first — skim the
-headings, read the sections you're about to touch; the bashio, s6-env, arch-guard and versioning
-traps are all live. (The light-path facts it holds — versioning format, CHANGELOG heading — are
-already inline in step 7.) Validate with `scripts/validate.sh <addon> --vs-master`. Write
-behavioural tests for anything with branches, targeting **the regression a reviewer described**,
-not just the happy path.
+Read the `references/traps.md` section matching what you're about to touch. It is ~18 KB and all
+but one section is irrelevant to any given edit, so print the one you need rather than reading the
+file — run it with no argument to list the sections:
+
+| Touching | Run |
+| --- | --- |
+| an option or anything a base-image service reads | `bash "$SKILL/scripts/traps.sh" passing` |
+| a file the app also writes itself | `bash "$SKILL/scripts/traps.sh" "app's own"` |
+| shell, bashio, a symlinked script | `bash "$SKILL/scripts/traps.sh" bashio` |
+| `Dockerfile`, `build.json`, an arch guard | `bash "$SKILL/scripts/traps.sh" dockerfile` |
+| Chromium, Electron, Xvfb | `bash "$SKILL/scripts/traps.sh" chromium` |
+
+Then validate with `scripts/validate.sh <addon> --vs-master`, and write behavioural tests for
+anything with branches, targeting **the regression a reviewer described**, not just the happy
+path.
 
 ## 5. Simplify
 
-Before requesting review, check: did the diff stay at the ladder level chosen in step 3? Can this
-be solved by deleting instead of adding? Is the fix bigger than what it fixes? How does it fail in
-three years? And on reuse: does any hunk reimplement something `.templates/`, another script in
-this add-on, or a sibling add-on already does — and if a future add-on hits this same problem,
-will it find one way to solve it or two? Fold a near-duplicate into the existing mechanism, or
-justify the divergence in the PR body — but never at the cost of an isolation rule
-`references/traps.md` documents: scripts shared by symlink with the webtop add-ons take a new
-numbered script, not an edit. Case studies of what happens when this check is skipped:
-`references/simplify.md`.
+Six questions over your own diff, before anyone else reads it:
+
+- **Level** — did the diff stay at the ladder level chosen in step 3, or creep up one?
+- **Deletion** — can this be solved by deleting instead of adding?
+- **Size** — is the fix bigger than the thing it fixes?
+- **Reuse** — does any hunk reimplement what `.templates/`, another script in this add-on, or a
+  sibling add-on already does? If a future add-on hits this problem, will it find one way to solve
+  it or two? Fold near-duplicates in, or justify the divergence in the PR body.
+- **Depth** — is this a special case bolted onto shared infrastructure? Fix the shared mechanism
+  instead once more than one add-on hits it; generalising from a single case is how bespoke
+  designs get built, so below that bar the special case is the right call.
+- **Longevity** — how does this fail in three years, when the base image or upstream has moved?
+
+The standing exception to Reuse and Depth: scripts shared by symlink with the webtop add-ons take a
+new numbered script, never an edit (`references/traps.md#shell-and-bashio`). Case studies for the rest, including
+what shipped when this pass was skipped: `references/simplify.md`.
 
 ## 6. Codex attacks the code, then simplify what the review added (full loop only)
 
 Same delegated invocation, pointed at `git diff origin/master...HEAD` plus your reasoning per
 hunk. Details in `references/codex-review.md`.
 
-Then run step 5's checks again over the hunks the review changed. Adversarial review only ever
-argues *for* another branch — that is its job — so accepting objections ratchets the diff upward,
-and nothing else in the loop walks it back down. For each accepted objection: is the case it
-defends one you have now demonstrated, or one you have merely been told about? Taking a
+Then run step 5's checks again over the hunks the review changed. Adversarial review mostly argues
+*for* another branch — that is what it is asked to do — so accepting objections tends to ratchet
+the diff upward, and nothing else in the loop walks it back down. Sort each objection before you
+write anything:
+**"this is wrong"** is a bug and you fix it; **"this is undefended"** is a claim about some host,
+and it needs the same demonstration you would demand of a measurement — is the case it defends one
+you have now demonstrated, or one you have merely been told about? Taking a
 correctness objection often deletes the code that made it necessary, and a fix that collapses back
 to fewer lines than you started the review with is the normal outcome, not a suspicious one.
 
@@ -165,20 +183,23 @@ kind of edit that leaves a stray `fi` behind.
 
 ## 7. Open the PR
 
-CI gates on a PR: **`CHANGELOG.md` updated** (hard fail), the **HA add-on linter**
-(`frenck/action-addon-linter`, blocking — not the weekly Super-Linter, which is non-blocking), and
-the **add-on image build**. Bump `version` anyway (`X.Y.Z.N`, never `X.Y.Z-N`, see
-`references/traps.md#versioning`) — Supervisor won't offer a rebuild without it. Update
-`README.md` if you added options; write the CHANGELOG heading as `## <version> (<date>)`,
-matching the date format already in that file — almost always ISO `YYYY-MM-DD`, see
-`references/traps.md#ci-and-review-bots`.
+Three hard gates — **`CHANGELOG.md` updated**, the **HA add-on linter**
+(`frenck/action-addon-linter`), and the **add-on image build** — but only on a PR that changes a
+top-level `config.*`. On a PR that doesn't (docs, `.github/`, `.claude/`) they *skip*, which is not
+the same as passing. Super-Linter runs on every PR and is `continue-on-error`, so it never blocks;
+fix its real findings anyway. Nothing checks the version bump, so bump it yourself — Supervisor
+won't offer a rebuild without one, and `CLAUDE.md` has the format. Update `README.md` if you added
+options; write the CHANGELOG heading as `## <version> (<date>)`, matching the date format already
+in that file — almost always ISO `YYYY-MM-DD`, see `references/traps.md#ci-and-review-bots`.
 
 Write the body to a file, `gh pr create --body-file`: state what was measured, what changed,
 **what is not verified**, and how to roll back the riskiest hunk alone.
 
 ## 8. Resolve review comments
 
-`scripts/pr_review.sh list|reply|resolve|status|watch <PR>`. For every comment, **reproduce the
+`scripts/pr_review.sh list|status|watch <PR>` to read, `reply <PR> <COMMENT_ID> <text|@file>` and
+`resolve <PR> <THREAD_ID…|--all>` to answer; run it with no arguments for the full usage. For every
+comment, **reproduce the
 claim before agreeing or disagreeing** — reviewers are frequently right and occasionally
 confidently wrong; a reproduction takes a minute and decides it either way. Reply with the
 evidence, then resolve. **Push back when you're right**, on the thread — a resolved-but-wrong
@@ -192,13 +213,12 @@ work" — either it was exercised, or say plainly it wasn't.
 
 Light path: verification is `validate.sh` plus CI; anything beyond that is Assumed. Full loop: CI
 passing proves the build works, not that the change does anything — re-run the measurement that
-motivated the work once the rebuilt add-on is running. After merge, `git fetch origin master`
-(the tracking ref is stale otherwise), then confirm the *changes* survived — `git diff
-origin/master -- <the paths you touched>` comes back empty. Ancestry is not the check: a revert
-leaves your commit in history and undoes its tree, so `--contains` reports success either way. The
-builder's revert-on-failure job can revert a merge for reasons unrelated to your diff (see
-`references/traps.md#ci-and-review-bots`). Real "merged and inert" examples, and what
-to do when a fix can't be self-verified: `references/evidence.md`.
+motivated the work once the rebuilt add-on is running. Real "merged and inert" examples, and what
+to do when a fix cannot be self-verified: `references/evidence.md`. Then confirm the change
+survived the merge: `git fetch origin master` first (the tracking ref is stale otherwise), then
+`git diff origin/master -- <the paths you touched>` must come back empty. Ancestry is not the
+check, and the builder reverts merges for reasons unrelated to your diff — both explained in
+`references/traps.md#ci-and-review-bots`.
 
 ## 10. Calibrate and report
 

.claude/skills/hassio-addon-workflow/references/codex-review.md

@@ -2,9 +2,7 @@
 
 Used for step 3 (plan review) and step 6 (code review), full loop only. Codex is a genuinely
 different model reading the files itself; on this workload it has repeatedly been worth the
-minutes. Delegate the invocation to a subagent (see SKILL.md's subagent-delegation note) so its
-output doesn't land verbatim in your context — have the subagent return only Codex's objections
-and your assessment of each.
+minutes. Run it through a subagent, per SKILL.md's delegation note.
 
 ## Invocation
 
@@ -12,11 +10,12 @@ and your assessment of each.
 on ~4 KB prompts (2026-08-03); the CLI with the same content succeeded. The MCP tool is still fine
 for short questions.
 
-`--sandbox read-only` lets Codex read files but blocks writes and command execution, and
-`approval_policy=never` means it will not be prompted for permission to run anything either — so
-paste every number into the prompt rather than expecting Codex to gather it. `- <` feeds the
-prompt file on stdin. Run it in the background so you are not blocked for the several minutes it
-takes (`&` here, or your harness's background-task mechanism):
+`--sandbox read-only` blocks writes, not reads, and `approval_policy=never` stops it asking for
+permission rather than stopping it acting — so it can still run read-only commands and often
+falls back to fetching the repo from GitHub instead of reading your worktree. Paste every number
+into the prompt rather than expecting it to gather them, and treat what it reports about *local*
+state as unverified. `- <` feeds the prompt file on stdin. Run it in the background so you are not
+blocked for the several minutes it takes (`&` here, or your harness's background-task mechanism):
 
 ```bash
 codex exec --model gpt-5.6-sol --sandbox read-only --skip-git-repo-check \
@@ -40,9 +39,5 @@ codex exec --model gpt-5.6-sol --sandbox read-only --skip-git-repo-check \
 confidently, and separately caught a genuine methodology error in the same review. Treat its
 confirmations with the same scepticism as its objections — especially about the build.
 
-**Its objections ratchet complexity upward.** An adversarial reviewer is asked to find what could
-go wrong, so its output is a list of arguments for more code; it is never asked whether the branch
-it wants is reachable. Separate "this is wrong" from "this is undefended" before you write
-anything: the first is a bug and you fix it, the second is a claim about some host, and it needs
-the same demonstration you would demand of a measurement. That is what step 6's second simplify
-pass is for.
+**Its objections only ever argue for more code** — it is asked what could go wrong, never whether
+the branch it wants is reachable. Sort them before writing anything; SKILL.md step 6 is that pass.

.claude/skills/hassio-addon-workflow/references/evidence.md

@@ -1,16 +1,24 @@
 # Evidence — measurement methodology and case studies
 
-## Why summed RSS and reserved-vs-resident both matter
+## How to read the numbers
 
-- **Summed RSS double-counts shared pages.** Removing a duplicate process frees its *private*
-  memory, not its RSS. `scripts/measure.sh` reports PSS and private alongside RSS — quote
-  **private** when arguing "removing this saves N MB".
-- **A big mapping is not necessarily resident.** Large SysV/tmpfs segments are lazily populated;
-  reserved size is reported separately from resident for this reason.
-- `/proc/meminfo` and `free` show **host** figures (no memory cgroup namespace here) — never
-  attribute those to the add-on.
-- Sample duration matters: a 3 s CPU sample measured 2.3% where a 20 s sample measured 21.6% for
-  the same process. Use ≥20 s for anything you report.
+**Summed RSS overstates savings.** Shared library pages are counted once per process, so removing
+a duplicate frees its *private* memory, not its RSS. Measured example: four MCP shims summed to
+882 MB RSS but 643 MB PSS / 564 MB private, and per-process private ranged 54 MB down to 2 MB —
+which completely changes which duplicate is worth removing. Quote private when arguing "removing
+this saves N MB".
+
+**A large mapping is often not resident.** SysV/tmpfs segments are lazily populated. Xvfb's
+506 MB framebuffer shows `Rss: 0` in `/proc/<pid>/smaps`. Check before calling anything a leak.
+
+**`/proc/meminfo` and `free` show host figures** — there is no memory cgroup namespace here.
+Never attribute those totals to the add-on.
+
+**A short CPU sample is not a CPU measurement.** A 3 s sample measured 2.3% where a 20 s sample
+measured 21.6% for the same process. Use >= 20 s for anything you report.
+
+`scripts/measure.sh` already reports PSS and private alongside RSS, and resident separately from
+reserved, so these three only bite when you compute a figure yourself or quote one from `ps`.
 
 ## Before asserting anything, ask what would show it false
 

.claude/skills/hassio-addon-workflow/references/simplify.md

@@ -30,28 +30,24 @@ Being able to build the complicated thing is not a reason to.
   It took the maintainer asking "is this the simplest way possible?" to run the pass that step 6
   now requires.
 
-## Checks worth running against your own diff
+## Where SKILL.md step 5's questions get hard
 
-- **Did the diff stay at the ladder level chosen in step 3?** If it crept up a level, either
-  justify that out loud or redo it at the level you chose.
-- **Can this be solved by deleting instead of adding?** A flag that shouldn't be passed, a
-  process that shouldn't start, a registration that shouldn't be duplicated. Deleting usually
-  shrinks the regression surface — but not always: the `/dev/shm` case in
-  `references/evidence.md` is a removal that reintroduced a crash loop on hosts unlike this one.
-  A removal that depends on a host default still needs the same verification as an addition.
-- **Is the fix bigger than the thing it fixes?** That is a smell, not a rule — but it usually
-  means the problem was framed one level too deep.
-- **For each defensive branch: what input reaches it, on which image or host?** Go and check,
-  the way you would check a measurement. The bar is being able to **name** the case, not to
-  reproduce it here: Docker's 64 MB `/dev/shm` default is documented behaviour that HA does not
-  override, so the bullet above keeps that guard even though this host measured 7.7 GB. Nobody
-  could name a single image shipping `with-contenv` without `s6-dumpenv`, so that fallback went.
-  If you cannot name the case, delete the branch — the situation then fails the way it already
-  fails today, visibly, instead of through a second path that is never exercised and silently
-  rots as the base images move. Weigh the cost too: a one-flag guard against a crash you cannot
-  rule out is cheap, a second code path that degrades to the pre-fix behaviour anyway is not.
-  Write down in the PR body what you cut and why, so the next person does not re-add it from the
-  same reasoning.
-- **How does this fail in three years**, when the base image, Electron, or upstream has moved?
-  Code that reads a documented knob keeps working. Code that reaches into private internals
-  does not.
+**Deletion is not automatically the safe direction.** The `/dev/shm` case in `evidence.md` is a
+removal that reintroduced a crash loop on hosts unlike this one. A removal that depends on a host
+default needs the same verification as an addition.
+
+**Naming the case is the bar for a defensive branch, not reproducing it.** Docker's 64 MB
+`/dev/shm` default is documented behaviour that Home Assistant does not override, so that guard
+stays even though this host measured 7.7 GB. Nobody could name a single image shipping
+`with-contenv` without `s6-dumpenv`, so that fallback went. If you cannot name the case, delete the
+branch: the situation then fails the way it already fails today, visibly, instead of through a
+second path that is never exercised and silently rots as the base images move. Weigh the cost both
+ways — a one-flag guard against a crash you cannot rule out is cheap; a second code path that
+degrades to the pre-fix behaviour anyway is not. Write in the PR body what you cut and why, so the
+next person does not re-add it from the same reasoning.
+
+**"Bigger than the thing it fixes" is a smell, not a rule** — but it usually means the problem was
+framed one level too deep.
+
+**Three-year failure** favours code that reads a documented knob. Code that reaches into private
+internals does not survive the base image moving.

.claude/skills/hassio-addon-workflow/references/traps.md

@@ -9,7 +9,6 @@ workflows and lint rules — that is not repeated here.
 ## Contents
 
 - [Environment and workspace](#environment-and-workspace)
-- [Measurement](#measurement)
 - [Passing values into base-image services](#passing-values-into-base-image-services)
 - [Writing into an app's own config](#writing-into-an-apps-own-config)
 - [Shell and bashio](#shell-and-bashio)
@@ -46,20 +45,6 @@ gate. One observed run took ~3 hours, with 20+ runs queued against 2 executing
 runner contention, not the diff. Check `gh run list` before concluding your PR is stuck. Poll in
 a background task, and never claim the build is verified when it hasn't run.
 
-## Measurement
-
-**Summed RSS overstates savings.** Shared library pages are counted once per process, so removing
-a duplicate frees its *private* memory, not its RSS. Measured example: four MCP shims summed to
-882 MB RSS but 643 MB PSS / 564 MB private, and per-process private ranged 54 MB down to 2 MB —
-which completely changes which duplicate is worth removing. Quote private when arguing "removing
-this saves N MB".
-
-**A large mapping is often not resident.** SysV/tmpfs segments are lazily populated. Xvfb's
-506 MB framebuffer shows `Rss: 0` in `/proc/<pid>/smaps`. Check before calling anything a leak.
-
-**`/proc/meminfo` and `free` show host figures** — there is no memory cgroup namespace here.
-Never attribute those totals to the add-on.
-
 **`rtk` filters some command output.** For a complete listing, redirect to a file and read that
 (`ps ... > $SP/ps.txt`), or use `rtk proxy <cmd>`.
 
@@ -85,10 +70,28 @@ service run scripts including `svc-xorg`, and Xvfb runs with `-vfbdevice /dev/dr
 
 - `00-global_var.sh` is cont-init **00**. Any cont-init script numbered higher runs *after* the
   injection, so it cannot change what a service will see through stage 2.
-- LSIO's `svc-xorg` starts `#!/usr/bin/env bashio`, **not** `with-contenv`, so it never reads
-  stage 3 at all. Writing `container_environment` for it is a silent no-op — that shipped: the
-  file was written 6 seconds before Xvfb started, and Xvfb still came up at the base-image
-  default.
+- **Whether a service's own shebang still decides stage 3 depends on whether `ha_entrypoint.sh`
+  runs as PID 1** — i.e. whether the add-on replaces the base `ENTRYPOINT ["/init"]` with one that
+  makes `ha_entrypoint.sh` itself the container's entrypoint (live today in `ente` and
+  `free_games_claimer`; `wger` has the override written into its Dockerfile but commented out, so
+  it is not currently one of these — check the Dockerfile, not this list). Under the normal
+  `/init` path this script runs as the stage-2 hook, `$PID1` is false, and it never touches
+  `services.d/*/run` or `s6-overlay/s6-rc.d/*/run` at all (`.templates/ha_entrypoint.sh:430`,
+  gated on `if $PID1`) — s6's own stage 1 already created `/run/s6/container_environment` before
+  any cont-init script ran, so a service's shipped `with-contenv` shebang reads it normally.
+  Only the `ENTRYPOINT`-override path breaks this, and it breaks it twice over: s6 stage 1 never
+  runs, so nothing ever creates the envdir; and because `ha_entrypoint.sh` is now PID 1, it
+  rewrites the first line of every service `run` file to whichever shebang its own
+  `candidate_shebangs` probe landed on. That probe's first candidate,
+  `/command/with-contenv bashio`, fails precisely because the envdir was never created, so it
+  falls through to `/usr/bin/env bashio` for every service — the real mechanism behind the shipped
+  `svc-xorg` failure (its envdir file was written 6 seconds before Xvfb started, and Xvfb still
+  came up at the base-image default). `cont-init.d` scripts are a separate case: `run_one_script`
+  rewrites their shebang unconditionally, with no `$PID1` gate, so a cont-init script's own
+  shebang is never informative either way. `ha_entrypoint.sh` dumps the environment itself to
+  compensate for the missing envdir, and the envdir writes in `00-global_var.sh` /
+  `01-config_yaml.sh` are `if [ -d ]` guarded, so they take effect only once something has created
+  that directory.
 
 **Renaming an option to match a base-image env var moves validation out of your script and into
 the schema.** `00-global_var.sh` exports empty strings (only objects/arrays/nulls are dropped),
@@ -190,11 +193,9 @@ build.
 
 ## Versioning
 
-**`X.Y.Z.N`, never `X.Y.Z-N`.** A hyphen parses as a semver pre-release, which Supervisor treats
-as *older* than `X.Y.Z` — the update is never offered.
-
-Date-based versions (`2026.08.03`) are common here. Check whether master has already moved to the
-version you were about to use.
+`CLAUDE.md` owns the format (`X.Y.Z.N`, never `X.Y.Z-N`, and why). The one thing it does not say:
+date-based versions (`2026.08.03`) are common here, so check whether master has already moved to
+the version you were about to use before you pick it.
 
 ## Chromium / Electron under Xvfb
 

.claude/skills/hassio-addon-workflow/scripts/preflight.sh

@@ -5,7 +5,14 @@
 # Usage: preflight.sh [repo-path] [addon-slug]
 set -uo pipefail
 
-REPO="${1:-/data/claude/hassio-addons}"
+# Default to the checkout this is run from, never a fixed path: a fixed path silently inspected
+# the main checkout while the caller worked in a worktree, reporting a branch nobody was editing —
+# the exact stale-checkout trap this script exists to catch. Falling back to one when git cannot
+# answer would recreate it, so refuse instead and make the caller say which repo they mean.
+REPO="${1:-}"
+if [ -z "$REPO" ]; then
+    REPO=$(git rev-parse --show-toplevel 2> /dev/null) || REPO=""
+fi
 SLUG="${2:-}"
 
 echo "== tools =="
@@ -26,9 +33,14 @@ fi
 echo
 echo "== repo =="
 # git-aware check: in a worktree .git is a file, not a directory
+if [ -z "$REPO" ]; then
+    echo "  not inside a git checkout, and no repo path given"
+    echo "  -> pass one explicitly: preflight.sh <repo-path> [addon-slug]"
+    exit 1
+fi
 if ! git -C "$REPO" rev-parse --git-dir > /dev/null 2>&1; then
     echo "  no git repo at $REPO"
-    exit 0
+    exit 1
 fi
 cd "$REPO" || exit 0
 branch=$(git branch --show-current 2> /dev/null || echo "(detached)")

.claude/skills/hassio-addon-workflow/scripts/traps.sh

@@ -0,0 +1,49 @@
+#!/usr/bin/env bash
+# Print one section of references/traps.md.
+#
+# traps.md is ~18 KB and every section but one is irrelevant to any given edit: a shell fix needs
+# 642 bytes of it, a Dockerfile fix 2.6 KB, and "CI and review bots" — 35% of the file — is needed
+# at steps 7-8 and never at step 4. A markdown anchor cannot be loaded on its own, so reading the
+# file to reach one section pays for all of them. This prints just the section, so the routing
+# table in SKILL.md step 4 costs what it claims to.
+#
+# Usage: traps.sh <keyword>   # substring of a section heading, case-insensitive
+#        traps.sh             # list the sections
+set -uo pipefail
+
+TRAPS="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)/references/traps.md"
+[ -f "$TRAPS" ] || { echo "not found: $TRAPS" >&2; exit 1; }
+
+# The Contents list duplicates the headings; grep the headings themselves so the list cannot drift.
+list() {
+    echo "sections (pass any substring):"
+    grep '^## ' "$TRAPS" | grep -v '^## Contents' | sed 's/^## /  /'
+}
+
+[ $# -eq 0 ] && { list; exit 0; }
+
+# awk over exact heading text: section names contain '/' and other characters that would need
+# escaping in a sed address, and a keyword matching several headings should be an error, not a
+# silent pick of the first.
+mapfile -t matches < <(grep '^## ' "$TRAPS" | grep -v '^## Contents' |
+    grep -iF -- "$1" | sed 's/^## //')
+
+case "${#matches[@]}" in
+    0)
+        echo "no section matching '$1'" >&2
+        list >&2
+        exit 1
+        ;;
+    1) ;;
+    *)
+        echo "'$1' matches ${#matches[@]} sections — be more specific:" >&2
+        printf '  %s\n' "${matches[@]}" >&2
+        exit 1
+        ;;
+esac
+
+awk -v want="## ${matches[0]}" '
+    $0 == want { inside = 1; print; next }
+    inside && /^## / { exit }
+    inside { print }
+' "$TRAPS"

.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@d75b94d5ad426cb8546e6628b6f5f19b84e5cce1  # 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@d75b94d5ad426cb8546e6628b6f5f19b84e5cce1  # 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@d75b94d5ad426cb8546e6628b6f5f19b84e5cce1  # 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@d75b94d5ad426cb8546e6628b6f5f19b84e5cce1  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Without this the action falls back to the OIDC -> Claude App token

.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@d75b94d5ad426cb8546e6628b6f5f19b84e5cce1  # v1
         with:
           claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
           # Skip the OIDC -> Claude App token exchange, which 401s whenever

.templates/01-config_yaml.sh

@@ -19,7 +19,7 @@ slug="${slug#*_}"
 if [ ! -f /config/configuration.yaml ] && [ ! -f /config/configuration.json ]; then
     # New config location
     CONFIGLOCATION="/config"
-    CONFIGFILEBROWSER="/addon_configs/${HOSTNAME/-/_}/config.yaml"
+    CONFIGFILEBROWSER="/app_configs/${HOSTNAME/-/_}/config.yaml"
 else
     # Legacy config location
     CONFIGLOCATION="/config/addons_config/${slug}"

.templates/01-custom_script.sh

@@ -174,7 +174,7 @@ slug="${slug#*_}"
 # Check type of config folder
 if [ ! -f /config/configuration.yaml ] && [ ! -f /config/configuration.json ]; then
   CONFIGLOCATION="/config"
-  CONFIGFILEBROWSER="/addon_configs/${HOSTNAME/-/_}/$slug.sh"
+  CONFIGFILEBROWSER="/app_configs/${HOSTNAME/-/_}/$slug.sh"
 else
   CONFIGLOCATION="/config/addons_autoscripts"
   CONFIGFILEBROWSER="/homeassistant/addons_autoscripts/$slug.sh"

.templates/ha_entrypoint.sh

@@ -16,6 +16,54 @@ else
   echo "Starting custom scripts"
 fi
 
+##########################################
+# Install the stop handler               #
+##########################################
+
+# As namespace PID 1 -- which is what "init: false" makes this script -- the kernel
+# discards any signal whose handler is still SIG_DFL. Installed at the end of startup,
+# as it used to be, the handler missed every stop that arrived while the Supervisor
+# probe or the cont-init chain was still running: Home Assistant waited out the grace
+# period for a SIGKILL and reported the add-on as failed. Nothing here is interrupted
+# mid-write by the move -- only PID 1 is signalled, and bash runs a trap at a command
+# boundary, so whatever external command is in flight reaps first.
+terminate() {
+  local local_pid
+  # Best-effort, so errexit must not apply: this runs with `set -e` in force (validate_shebang
+  # leaves it on), and under errexit the first failing command aborts the handler and exits with
+  # its status, skipping the child-kill loop and the `exit 0` below. Every command in the body
+  # here is already guarded, but add-ons patch this function at build time -- postgres_15 and
+  # postgres_17 sed an unguarded `pg_ctl ... stop` in right after the echo -- and that command
+  # fails whenever the stop arrives before the database is up.
+  set +e
+  echo "Termination signal received, forwarding to subprocesses..."
+  if command -v pgrep >/dev/null 2>&1; then
+    while read -r pid; do
+      [ -n "$pid" ] || continue
+      echo "Terminating child PID $pid"
+      kill -TERM "$pid" 2>/dev/null || echo "Failed to terminate PID $pid"
+    done < <(pgrep -P "$$" || true)
+  else
+    for p in /proc/[0-9]*/; do
+      local_pid="${p#/proc/}"
+      local_pid="${local_pid%/}"
+      if [ "$local_pid" -ne 1 ] && grep -q "^PPid:[[:space:]]*$$" "/proc/$local_pid/status" 2>/dev/null; then
+        echo "Terminating child PID $local_pid"
+        kill -TERM "$local_pid" 2>/dev/null || echo "Failed to terminate PID $local_pid"
+      fi
+    done
+  fi
+  wait || true
+  echo "All subprocesses terminated. Exiting."
+  exit 0
+}
+
+# Only when this script is PID 1. Under Docker's own init the entrypoint is an ordinary
+# child and the signal handling above belongs to that init, not to us.
+if $PID1; then
+  trap terminate SIGTERM SIGINT
+fi
+
 ##########################################
 # Pick an exec-capable directory         #
 ##########################################
@@ -428,31 +476,6 @@ if $PID1; then
   echo " "
   echo -e "\033[0;32mEverything started!\033[0m"
 
-  terminate() {
-    local local_pid
-    echo "Termination signal received, forwarding to subprocesses..."
-    if command -v pgrep >/dev/null 2>&1; then
-      while read -r pid; do
-        [ -n "$pid" ] || continue
-        echo "Terminating child PID $pid"
-        kill -TERM "$pid" 2>/dev/null || echo "Failed to terminate PID $pid"
-      done < <(pgrep -P "$$" || true)
-    else
-      for p in /proc/[0-9]*/; do
-        local_pid="${p#/proc/}"
-        local_pid="${local_pid%/}"
-        if [ "$local_pid" -ne 1 ] && grep -q "^PPid:[[:space:]]*$$" "/proc/$local_pid/status" 2>/dev/null; then
-          echo "Terminating child PID $local_pid"
-          kill -TERM "$local_pid" 2>/dev/null || echo "Failed to terminate PID $local_pid"
-        fi
-      done
-    fi
-    wait || true
-    echo "All subprocesses terminated. Exiting."
-    exit 0
-  }
-
-  trap terminate SIGTERM SIGINT
   while :; do
     sleep infinity &
     wait $!

CLAUDE.md

@@ -70,7 +70,7 @@ version: "X.Y.Z"          # upstream version (format varies; see Versioning sect
 ingress: true/false
 ingress_port: 8000
 map:
-  - addon_config:rw        # /addon_configs/<hostname>/
+  - app_config:rw        # /app_configs/<hostname>/
   - share:rw
   - media:rw
   - ssl

addons_updater/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 ## 2026.08 (2026-08-01)
 
 - Addon versions written in config.yaml now always comply with Home Assistant versioning: an upstream tag Home Assistant cannot order (`version-bf9e0b4f`, `ubuntu-2026-06-01`, ...) or would sort as older (`1.2.3-2`, `1.2.3+4`) no longer lands in config.yaml. The addon number is incremented instead, while the raw upstream tag stays in updater.json so the same release is never published twice
@@ -31,7 +32,7 @@
 
 ## 3.19
 
-- New HA config logic implemented. Files are now located in the addon config file, that can be accessed from the addon_configs folder from my filebrowser or cloudcommander addons. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
+- New HA config logic implemented. Files are now located in the addon config file, that can be accessed from the app_configs folder from my filebrowser or cloudcommander addons. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
 - Feat : if there is no releases in a github repo, check if there is a valid package and get the highest tag https://github.com/alexbelgium/hassio-addons/issues/1168
 - Feat : github_exclude applies to dockerhub
 

addons_updater/README.md

@@ -115,7 +115,7 @@ verbose: "false"
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **Environment variables**: Use the add-on `env_vars` option and see [Add Environment Variables to your Addon](https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon) for details.

addons_updater/config.yaml

@@ -8,7 +8,7 @@ environment:
 image: ghcr.io/alexbelgium/addons_updater-{arch}
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
 name: Repository Updater
 options:
   date_iso8601: true

aurral/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 2.8.0 (2026-09-05)
 - Update to latest version from lklynet/aurral (changelog : https://github.com/lklynet/aurral/releases)

aurral/config.yaml

@@ -21,7 +21,7 @@ ports_description:
 webui: http://[HOST]:[PORT:3001]
 
 map:
-  - addon_config:rw
+  - app_config:rw
   - share:rw
   - media:rw
 

baikal/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 ## 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
@@ -28,7 +29,7 @@
 ## 0.9.5 (2024-04-27)
 - Update to latest version from ckulka/baikal-docker (changelog : https://github.com/ckulka/baikal-docker/releases)
 ## 0.9.4-3 (2024-04-26)
-- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/baikal to a folder only accessible from my Filebrowser addon called /addon_configs/something-baikal. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
+- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/baikal to a folder only accessible from my Filebrowser addon called /app_configs/something-baikal. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
 
 ## 0.9.4-2 (2024-01-14)
 

baikal/README.md

@@ -50,7 +50,7 @@ Configurations can be done through the app webUI, except for the following optio
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **Environment variables**: See [Add Environment Variables to your Addon](https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon)

baikal/config.yaml

@@ -66,7 +66,7 @@ devices:
   - /dev/nvme2
 image: ghcr.io/alexbelgium/baikal-{arch}
 map:
-  - addon_config:rw
+  - app_config:rw
   - homeassistant_config:rw
   - share:rw
   - ssl:ro

battybirdnet-pi/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 ## 2026.02.28 (28-02-2026)
 - Minor bugs fixed
 ## 2026.02.25-2 (25-02-2026)

battybirdnet-pi/README.md

@@ -86,7 +86,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

battybirdnet-pi/config.yaml

@@ -64,7 +64,7 @@ ingress: true
 ingress_stream: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
   - ssl

bazarr/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 
 ## 1.6.0.2 (2026-07-27)
 
@@ -26,7 +27,7 @@
 - Update to latest version from linuxserver/docker-bazarr (changelog : https://github.com/linuxserver/docker-bazarr/releases)
 
 ## 1.5.4-1 (2026-01-08)
-- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/addons_config/bazarr to a folder only accessible from my Filebrowser addon called /addon_configs/xxx-bazarr. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
+- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/addons_config/bazarr to a folder only accessible from my Filebrowser addon called /app_configs/xxx-bazarr. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
 
 ## 1.5.4 (2026-01-08)
 - Update to latest version from linuxserver/docker-bazarr (changelog : https://github.com/linuxserver/docker-bazarr/releases)

bazarr/config.yaml

@@ -76,7 +76,7 @@ ingress: true
 ingress_entry: bazarr
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - homeassistant_config:rw
   - share:rw
   - media:rw

bazarr/rootfs/etc/cont-init.d/20-folders.sh

@@ -23,7 +23,7 @@ fi
 slug=bazarr
 
 if [ -d "/homeassistant/addons_config/$slug" ]; then
-    echo "Migrating /homeassistant/addons_config/$slug to /addon_configs/xxx-$slug"
+    echo "Migrating /homeassistant/addons_config/$slug to /app_configs/xxx-$slug"
     cp -rnf /homeassistant/addons_config/"$slug"/. /config/ || true
     mv /homeassistant/addons_config/"$slug" /homeassistant/addons_config/"$slug"_migrated
 fi

birdnet-go-dev/CHANGELOG.md

@@ -1,3 +1,29 @@
+## 20260910.2 (11-09-2026)
+- Minor bugs fixed
+## 20260910 (11-09-2026)
+- Migrate legacy add-on configuration map names to current app configuration terminology.
+## 20260909.7 (10-09-2026)
+- Correct the "first daily detection consensus" README section (review feedback on PR #3056): a merged-upstream setting stays in the build rather than disappearing, every attempt for a species is held back until one is accepted rather than only the first, and the "known to every active bird model" exemption is scoped per audio source, matching the implementation.
+## 20260909.6 (10-09-2026)
+- Document the fork-only "first daily detection consensus" setting (alexbelgium/birdnet-go#63): requires a second model to confirm each bird species' first detection of the day. Off by default; no behaviour change unless enabled.
+## 20260909.5 (09-09-2026)
+- Minor bugs fixed
+## 20260909.4 (09-09-2026)
+- Minor bugs fixed
+## 20260909.3 (09-09-2026)
+- Minor bugs fixed
+## 20260909.2 (09-09-2026)
+- Minor bugs fixed
+## 20260909 (09-09-2026)
+- Minor bugs fixed
+## 20260908.2 (08-09-2026)
+- Minor bugs fixed
+## 20260908.1 (08-09-2026)
+- Synced with upstream birdnet-go (4 commits); re-merges the open fork PRs, adding fork PR #62 (reanalyze a clip with every loaded model + one-click correction)
+## 20260908 (08-09-2026)
+- Synced with upstream birdnet-go (7 commits); re-merges the open fork PRs
+## 20260907 (07-09-2026)
+- Rebuild: re-merges the open fork PRs, picking up the updated fork PR #57
 ## 20260901.4 (01-09-2026)
 - Minor bugs fixed
 ## 20260901.3 (01-09-2026)

birdnet-go-dev/HAINTEGRATION.md

@@ -25,7 +25,7 @@ MQTT password : Ri5ahV1aipeiw0aelerooteixai5ohtoeNg6oo3mo0thi5te0phiezuge4Phoore
 MQTT broker : tcp://core-mosquitto:1883
 ---
 
-Edit this section of config.yaml found in addon_configs/db21ed7f_birdnet-go/:
+Edit this section of config.yaml found in app_configs/db21ed7f_birdnet-go/:
     mqtt:
         enabled: true # true to enable MQTT
         broker: tcp://core-mosquitto:1883 # MQTT (tcp://host:port)

birdnet-go-dev/README.md

@@ -1,6 +1,6 @@
 # Home assistant add-on: Birdnet-Go (from source)
 
-> **⚠️ Test build.** This is a special variant of the [standard birdnet-go add-on](https://github.com/alexbelgium/hassio-addons/tree/master/birdnet-go). Instead of pulling the prebuilt `ghcr.io/tphakala/birdnet-go` image, it **compiles BirdNET-Go from the [`alexbelgium/birdnet-go`](https://github.com/alexbelgium/birdnet-go) fork**. At build time it syncs the fork's `main` with the `tphakala/birdnet-go` upstream and **merges every open non-draft ("in review") pull request on the fly** (see [`merge-prs.sh`](./merge-prs.sh)), so the binary reflects upstream main plus all work currently under review. Everything below is identical to the standard add-on.
+> **⚠️ Test build.** This is a special variant of the [standard birdnet-go add-on](https://github.com/alexbelgium/hassio-addons/tree/master/birdnet-go). Instead of pulling the prebuilt `ghcr.io/tphakala/birdnet-go` image, it **compiles BirdNET-Go from the [`alexbelgium/birdnet-go`](https://github.com/alexbelgium/birdnet-go) fork**. At build time it syncs the fork's `main` with the `tphakala/birdnet-go` upstream and **merges every open non-draft ("in review") pull request on the fly** (see [`merge-prs.sh`](./merge-prs.sh)), so the binary reflects upstream main plus all work currently under review. Everything below is identical to the standard add-on, except the fork-only settings listed under [Fork-only settings](#fork-only-settings).
 
 
 
@@ -65,6 +65,38 @@ Additional variables can be configured using the config.yaml file found in /conf
 - Config_env.yaml
 Additional environment variables can be configured there
 
+### Fork-only settings
+
+These are currently fork-only settings from the [`alexbelgium/birdnet-go`](https://github.com/alexbelgium/birdnet-go) fork and are **not** in the standard add-on. [`merge-prs.sh`](./merge-prs.sh) syncs the fork's `main` with upstream before applying open PRs, so once a PR merges upstream the setting stays in this build — it just arrives via that sync instead of the PR-merge step, and stops being fork-only. Only a PR that is **closed without merging** drops its setting from later builds.
+
+#### First daily detection consensus
+
+Requires a second model to confirm the **first** detection of each bird species each day. Until one is accepted, every attempt for that species is held to the same two-model bar; only once a detection clears it does every later detection that day behave exactly as it does today, on a single model.
+
+The first detection of a species in a day is the weakest evidence the pipeline produces, and it is the one that creates a "new species today" entry. Asking two models to agree on just that one detection removes most spurious new-species entries without slowing anything else down.
+
+**Off by default.** Turn it on in the web UI under *Settings → Filters → First Daily Detection Consensus*, or in `config.yaml`:
+
+```yaml
+realtime:
+  firstdailyconsensus:
+    enabled: true
+```
+
+The setting is re-read on each detection cycle, so it takes effect without restarting the add-on.
+
+It deliberately does **nothing** in these cases, all of which keep today's single-model behaviour:
+
+- you run only one bird model (the default) — a second opinion does not exist, so the rule can never trigger
+- the species is not a bird — bats and the non-bird sound classes Perch reports (insects, amphibians, mammals, `power_tool`, and so on)
+- the species is not known to *every* active bird model analyzing that audio source — a species only one of them can name could never reach two confirmations. With several sources running different model combinations, this is decided per source, not add-on-wide
+- a dynamic threshold has actually lowered the bar for that species, meaning you asked for a more permissive gate
+- the taxonomy or the database cannot be consulted — it fails open and accepts the detection
+
+In practice it only bites when a single audio source has two or more bird models (for example BirdNET plus Perch) analyzing it, on species all of them can identify. The trade is fewer false new-species entries, at the cost of occasionally delaying a genuine first sighting until a second model agrees.
+
+Requires [alexbelgium/birdnet-go#63](https://github.com/alexbelgium/birdnet-go/pull/63).
+
 ### MQTT and MariaDB auto-configuration (opt-in)
 
 If the Home Assistant **MQTT** addon is installed and running and you set `mqtt_auto_config: true` in the addon options, the addon writes the HA Mosquitto credentials directly into BirdNET-Go's `config.yaml` on every startup: `realtime.mqtt.enabled`, `broker`, `username`, and `password` are populated, and the topic defaults to `birdnet`. In addition, it enables BirdNET-Go's **native Home Assistant MQTT auto-discovery** (`realtime.mqtt.homeassistant.enabled`), so the detection sensors show up in Home Assistant automatically — **no manual MQTT sensor YAML required** (the hand-written sensors in [HAINTEGRATION.md](./HAINTEGRATION.md) remain available if you prefer to build your own). Messages are also retained (`realtime.mqtt.retain: true`) so sensor states survive Home Assistant restarts. When the option is `false` (the default), the addon still logs the broker details and reminds you about the option whenever Mosquitto is detected — nothing is written.
@@ -82,7 +114,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

birdnet-go-dev/config.yaml

@@ -80,7 +80,7 @@ ingress_entry: "ui/dashboard"
 ingress_stream: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
 name: Birdnet-go (customized and built from source)
@@ -127,5 +127,5 @@ slug: birdnet-go-dev
 udev: true
 url: https://github.com/alexbelgium/hassio-addons
 usb: true
-version: "20260901.4"
+version: "20260910.2"
 video: true

birdnet-go-dev/merge-prs.sh

@@ -11,6 +11,15 @@
 # stamping) is written to the directory given as $1 so the Docker build can
 # compile it.
 #
+# With --check the script does not build anything: it performs the exact same
+# merge sequence, skips (instead of failing on) every conflicting PR, and prints
+# one "!!! CONFLICT pr=#N conflicts-with=... files=... " line per offender before
+# exiting 2. Use it to find conflicts *before* a build burns on them. This is a
+# different question from GitHub's `mergeable` field, which compares a PR against
+# its own base ref - for a stacked PR that base is another feature branch (often
+# stale, sometimes belonging to a closed PR), so GitHub can report CLEAN for a PR
+# that does not merge onto main at all.
+#
 # Environment:
 #   BIRDNET_FORK       owner/repo of the fork           (default alexbelgium/birdnet-go)
 #   BIRDNET_UPSTREAM   owner/repo of the upstream        (default tphakala/birdnet-go)
@@ -19,7 +28,26 @@
 #
 set -euo pipefail
 
-TARGET_DIR="${1:?usage: merge-prs.sh <target-dir>}"
+CHECK_ONLY="${MERGE_PRS_CHECK:-0}"
+TARGET_DIR=""
+while [ "$#" -gt 0 ]; do
+    case "$1" in
+        --check) CHECK_ONLY=1 ;;
+        -*) echo "unknown option: $1" >&2; exit 64 ;;
+        *)
+            # Last-one-wins would silently clone into the wrong directory if a caller ever
+            # appended an argument; the pre-flag script used "${1}", so refuse rather than
+            # quietly change which operand counts.
+            if [ -n "${TARGET_DIR}" ]; then
+                echo "usage: merge-prs.sh [--check] <target-dir>" >&2
+                exit 64
+            fi
+            TARGET_DIR="$1"
+            ;;
+    esac
+    shift
+done
+: "${TARGET_DIR:?usage: merge-prs.sh [--check] <target-dir>}"
 
 FORK="${BIRDNET_FORK:-alexbelgium/birdnet-go}"
 UPSTREAM="${BIRDNET_UPSTREAM:-tphakala/birdnet-go}"
@@ -33,6 +61,52 @@ GH_TOKEN="${GH_TOKEN:-${GITHUB_TOKEN:-}}"
 
 log() { echo ">>> $*"; }
 
+# Conflicting PRs collected in --check mode: "number|scope|files|title".
+conflicting=()
+
+LOCKFILE="frontend/package-lock.json"
+
+# The single place that decides whether a conflicted merge is still acceptable.
+# package-lock.json is generated content and stacked PRs can carry an older copy even when
+# their source changes merge cleanly, so keep the lockfile already assembled on the base side
+# — but only when it is the sole conflict. Any source conflict stays fatal.
+# Returns 0 when it resolved and committed such a merge, 1 when the conflict is real.
+# BOTH the real merge and the --check probe must go through here: when only the real merge
+# applied the policy, the probe called a PR "conflicts-with=main" that the build would have
+# merged fine, and printed the opposite remediation to the true one.
+resolve_sole_lockfile() {
+    local dir="$1"
+    local -a conflicted
+    mapfile -t conflicted < <(git -C "${dir}" diff --name-only --diff-filter=U)
+    if [ "${#conflicted[@]}" -ne 1 ] || [ "${conflicted[0]}" != "${LOCKFILE}" ]; then
+        return 1
+    fi
+    log "Resolving generated ${LOCKFILE} conflict using the base tree"
+    git -C "${dir}" checkout --ours -- "${LOCKFILE}" || return 1
+    git -C "${dir}" add "${LOCKFILE}" || return 1
+    git -C "${dir}" commit --no-edit > /dev/null || return 1
+}
+
+# Does ${1} merge cleanly onto the pristine upstream-synced main? Probed in a
+# throwaway worktree so the accumulated tree is left untouched. Tells apart a PR
+# that is simply stale against main (fixable inside that PR's own branch) from
+# one that only clashes with another open PR (needs a cross-PR decision).
+merges_onto_main() {
+    local sha="$1" tmpdir probe rc=0
+    tmpdir="$(mktemp -d)"
+    probe="${tmpdir}/probe"
+    git worktree add --quiet --detach "${probe}" "${MAIN_SYNCED}"
+    if ! git -C "${probe}" merge --no-edit --no-ff -m probe "${sha}" > /dev/null 2>&1; then
+        # Same policy as the real merge, or this misclassifies a lockfile-only clash.
+        resolve_sole_lockfile "${probe}" > /dev/null 2>&1 || rc=1
+    fi
+    git worktree remove --force "${probe}" > /dev/null 2>&1 || true
+    # worktree remove only takes the child back; without this the mktemp parent is left behind
+    # on every checked conflict.
+    rmdir "${tmpdir}" > /dev/null 2>&1 || true
+    return "${rc}"
+}
+
 git config --global user.email "addon-builder@users.noreply.github.com"
 git config --global user.name "BirdNET-Go Addon Builder"
 git config --global advice.detachedHead false
@@ -47,6 +121,7 @@ git remote add upstream "${UPSTREAM_URL}"
 git fetch --no-tags upstream main
 # --no-ff keeps an explicit sync commit; a no-op when main is already current.
 git merge --no-edit --no-ff upstream/main
+MAIN_SYNCED="$(git rev-parse HEAD)"
 
 log "Querying open non-draft PRs from ${FORK}"
 auth_header=()
@@ -79,27 +154,43 @@ for entry in "${prs[@]}"; do
     if ! git merge --no-edit --no-ff -m "Merge PR #${number}: ${title}" "${sha}"; then
         mapfile -t conflicted_files < <(git diff --name-only --diff-filter=U)
 
-        # package-lock.json is generated content and stacked PRs can carry an
-        # older copy even when their source changes merge cleanly. Keep the
-        # lockfile already assembled from upstream and earlier PRs, but only
-        # when it is the sole conflict. Any source conflict remains fatal.
-        if [ "${#conflicted_files[@]}" -eq 1 ] \
-            && [ "${conflicted_files[0]}" = "frontend/package-lock.json" ]; then
-            log "Resolving generated frontend/package-lock.json conflict using the accumulated tree"
-            git checkout --ours -- frontend/package-lock.json
-            git add frontend/package-lock.json
-            git commit --no-edit
+        if resolve_sole_lockfile .; then
+            : # generated lockfile only - the merge is committed and the build continues
         else
             echo "!!! Merge conflict while merging PR #${number} (${title})." >&2
             if [ "${#conflicted_files[@]}" -gt 0 ]; then
                 printf '!!! Conflicting file: %s\n' "${conflicted_files[@]}" >&2
             fi
-            echo "!!! Resolve the conflict in the fork or pause this PR, then rebuild." >&2
             git merge --abort || true
+
+            if [ "${CHECK_ONLY}" = "1" ]; then
+                scope="accumulated"
+                merges_onto_main "${sha}" || scope="main"
+                conflicting+=("${number}|${scope}|${conflicted_files[*]:-}|${title}")
+                log "check mode: skipping PR #${number}, continuing with the rest"
+                continue
+            fi
+
+            echo "!!! Resolve the conflict in the fork or pause this PR, then rebuild." >&2
             exit 1
         fi
     fi
 done
 
+if [ "${CHECK_ONLY}" = "1" ]; then
+    if [ "${#conflicting[@]}" -eq 0 ]; then
+        log "CHECK OK: every open non-draft PR merges into the combined build tree"
+        exit 0
+    fi
+    echo "!!! CHECK FAILED: ${#conflicting[@]} PR(s) would break the add-on build" >&2
+    for entry in "${conflicting[@]}"; do
+        IFS='|' read -r number scope files title <<<"${entry}"
+        echo "!!! CONFLICT pr=#${number} conflicts-with=${scope} files=${files} title=${title}" >&2
+    done
+    echo "!!! conflicts-with=main     -> the PR is stale against main; merge main into its branch and resolve there." >&2
+    echo "!!! conflicts-with=accumulated -> the PR only clashes with another open PR; decide which one owns the hunk." >&2
+    exit 2
+fi
+
 log "Merged HEAD: $(git rev-parse --short HEAD)"
 log "Source tree ready at ${TARGET_DIR}"

birdnet-go/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 20260827 (2026-08-29)
 - Update to latest version from tphakala/birdnet-go (changelog : https://github.com/tphakala/birdnet-go/releases)

birdnet-go/HAINTEGRATION.md

@@ -25,7 +25,7 @@ MQTT password : Ri5ahV1aipeiw0aelerooteixai5ohtoeNg6oo3mo0thi5te0phiezuge4Phoore
 MQTT broker : tcp://core-mosquitto:1883
 ---
 
-Edit this section of config.yaml found in addon_configs/db21ed7f_birdnet-go/:
+Edit this section of config.yaml found in app_configs/db21ed7f_birdnet-go/:
     mqtt:
         enabled: true # true to enable MQTT
         broker: tcp://core-mosquitto:1883 # MQTT (tcp://host:port)

birdnet-go/README.md

@@ -79,7 +79,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

birdnet-go/config.yaml

@@ -81,7 +81,7 @@ ingress_entry: "ui/dashboard"
 ingress_stream: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
 name: Birdnet-go

birdnet-pi-zach/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 ## 2026.08.15 (15-08-2026)
 
 - Fix: `ALSA_CARD` now really selects the microphone. Its value was copied as-is into `REC_CARD`, but BirdNET-Pi hands `REC_CARD` to `arecord -D` / `ffmpeg -f alsa -i`, which expect an ALSA PCM name: a card index such as `1` gave `Unknown PCM 1` and no recording at all. It is now converted to `plughw:CARD=<value>,DEV=0`, while a value that already is a PCM name (`dsnoop:CARD=Audio,DEV=0`, `default`, `null`, `pulse`, `pipewire`, ...) is used as provided

birdnet-pi-zach/README.md

@@ -93,7 +93,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

birdnet-pi-zach/config.yaml

@@ -61,7 +61,7 @@ image: ghcr.io/alexbelgium/birdnet-pi-zach-{arch}
 ingress: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
   - ssl

birdnet-pi/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 ## 2026.08.15 (15-08-2026)
 
 - Fix: `ALSA_CARD` now really selects the microphone. Its value was copied as-is into `REC_CARD`, but BirdNET-Pi hands `REC_CARD` to `arecord -D` / `ffmpeg -f alsa -i`, which expect an ALSA PCM name: a card index such as `1` gave `Unknown PCM 1` and no recording at all. It is now converted to `plughw:CARD=<value>,DEV=0`, while a value that already is a PCM name (`dsnoop:CARD=Audio,DEV=0`, `default`, `null`, `pulse`, `pipewire`, ...) is used as provided
@@ -156,7 +157,7 @@
 - [ALL] Fix non-avx2 cpu support
 
 ## 2025.02.23 (2025-02-16)
-- WARNING 2025.02.14/16 was buggy. If you installed it you need to restore a backup or delete manually your /addon_configs/xxx-birdnet-pi/birdnet.conf file and recreate it
+- WARNING 2025.02.14/16 was buggy. If you installed it you need to restore a backup or delete manually your /app_configs/xxx-birdnet-pi/birdnet.conf file and recreate it
 - Allow usage as a standalone container (thanks @gotschi) https://github.com/mcguirepr89/BirdNET-Pi/issues/211#issuecomment-2650095952
 - Corrected a bug preventing to create db
 - Corrected a bug to ensure the the most up-to-date birdnet.conf on fresh start

birdnet-pi/README.md

@@ -93,7 +93,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

birdnet-pi/config.yaml

@@ -61,7 +61,7 @@ image: ghcr.io/alexbelgium/birdnet-pi-{arch}
 ingress: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
   - ssl

birdnet-pipy/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 0.8.8 (2026-08-22)
 - Update to latest version from Suncuss/BirdNET-PiPy (changelog : https://github.com/Suncuss/BirdNET-PiPy/releases)

birdnet-pipy/README.md

@@ -47,7 +47,7 @@ This add-on supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This add-on supports custom scripts and environment variables through the `addon_config` mapping:
+This add-on supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

birdnet-pipy/config.yaml

@@ -67,7 +67,7 @@ ingress: true
 ingress_stream: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - ssl:rw
   - share:rw
 name: BirdNET-PiPy

browser_brave/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 1.94.121-ls127 (2026-09-05)
 - Update to latest version from linuxserver/docker-brave (changelog : https://github.com/linuxserver/docker-brave/releases)

browser_brave/config.yaml

@@ -26,7 +26,7 @@ image: ghcr.io/alexbelgium/brave-{arch}
 ingress: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
   - ssl

browser_chromium/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 2026.09.05 (2026-09-05)
 - Update to latest version from linuxserver/docker-chromium (changelog : https://github.com/linuxserver/docker-chromium/releases)

browser_chromium/config.yaml

@@ -26,7 +26,7 @@ image: ghcr.io/alexbelgium/chromium-{arch}
 ingress: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
   - ssl

browserless_chrome/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 2.56.3 (2026-09-05)
 - Update to latest version from browserless/chrome (changelog : https://github.com/browserless/chrome/releases)

browserless_chrome/README.md

@@ -50,7 +50,7 @@ TIMEOUT: 60000
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

browserless_chrome/config.yaml

@@ -69,7 +69,7 @@ environment:
 image: ghcr.io/alexbelgium/browserless_chrome-{arch}
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
 name: Browserless Chromium
 options:
   env_vars: []

calibre/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 9.14.0 (2026-08-29)
 - Update to latest version from linuxserver/docker-calibre (changelog : https://github.com/linuxserver/docker-calibre/releases)
@@ -223,7 +224,7 @@
 
 - Update to latest version from linuxserver/docker-calibre
 - BREAKING CHANGE : please relink your library according to https://github.com/alexbelgium/hassio-addons/issues/1154#issuecomment-1879182729
-- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/calibre to a folder only accessible from my Filebrowser addon called /addon_configs/something-calibre. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/ https://github.com/alexbelgium/hassio-addons/issues/1154
+- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/calibre to a folder only accessible from my Filebrowser addon called /app_configs/something-calibre. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/ https://github.com/alexbelgium/hassio-addons/issues/1154
 
 ## 7.2.0 (2023-12-16)
 

calibre/README.md

@@ -98,7 +98,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

calibre/config.yaml

@@ -78,7 +78,7 @@ init: false
 map:
   - media:rw
   - share:rw
-  - addon_config:rw
+  - app_config:rw
   - homeassistant_config:rw
   - ssl
 name: Calibre

calibre_web/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 0.6.27.4 (2026-09-04)
 - Fix: Kobo sync could not be enabled, failing with "Kepubify binary not found" even when the path was set by hand. The LinuxServer base image installs the converter as `/usr/bin/kepubify` with `curl -o`, which leaves it mode 0644 and gives it a name calibre-web does not accept : `binary_helper.py` only takes `kepubify-linux-64bit` or `kepubify-linux-32bit`, and only when `os.access(X_OK)` passes. The addon now makes the binary executable and publishes it as `/opt/kepubify/kepubify-linux-64bit`, the directory calibre-web's own autodetection already probes, so the path is filled in without any manual step (https://github.com/alexbelgium/hassio-addons/issues/3040)
@@ -28,7 +29,7 @@
 - Update to latest version from linuxserver/docker-calibre-web (changelog : https://github.com/linuxserver/docker-calibre-web/releases)
 ## 0.6.24-10 (2025-05-28)
 - Fix migration script
-- Allow access to Calibre folder through /addon_configs/xxx-Calibre
+- Allow access to Calibre folder through /app_configs/xxx-Calibre
 
 ## 0.6.24 (2024-11-23)
 - Update to latest version from linuxserver/docker-calibre-web (changelog : https://github.com/linuxserver/docker-calibre-web/releases)
@@ -44,7 +45,7 @@
 - Minor bugs fixed
 ## 0.6.21-5 (2024-01-12)
 
-- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/calibre-web to a folder only accessible from my Filebrowser addon called /addon_configs/something-calibre-web. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/ https://github.com/alexbelgium/hassio-addons/issues/1177
+- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/calibre-web to a folder only accessible from my Filebrowser addon called /app_configs/something-calibre-web. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/ https://github.com/alexbelgium/hassio-addons/issues/1177
 
 ## 0.6.21-2 (2023-11-05)
 

calibre_web/config.yaml

@@ -77,8 +77,8 @@ image: ghcr.io/alexbelgium/calibre_web-{arch}
 ingress: true
 init: false
 map:
-  - addon_config:rw
-  - all_addon_configs:rw
+  - app_config:rw
+  - all_app_configs:rw
   - homeassistant_config:rw
   - media:rw
   - share:rw

claude_desktop/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 07308545.6 (2026-09-05)
 - Update to latest version from aaddrick/claude-desktop-debian (changelog : https://github.com/aaddrick/claude-desktop-debian/releases)

claude_desktop/SIGN_IN.md

@@ -63,7 +63,7 @@ magic link into the in-session Chromium (not a phone).
 - Add-on Configuration → `additional_apps: chromium`, restart (installed by
   `rootfs/etc/cont-init.d/80-configuration.sh`).
 - Add the two `xdg-settings`/`xdg-mime` commands to the custom script
-  `/addon_configs/db21ed7f_claude-desktop/claude_desktop.sh` (the image ships no standalone
+  `/app_configs/db21ed7f_claude-desktop/claude_desktop.sh` (the image ships no standalone
   terminal).
 
 ---

claude_desktop/config.yaml

@@ -34,7 +34,7 @@ hassio_role: manager
 homeassistant_api: true
 auth_api: true
 map:
-  - addon_config:rw
+  - app_config:rw
   - share:rw
   - media:rw
   - ssl

cleanuparr/CHANGELOG.md

@@ -1,3 +1,5 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
+- Fix persistent data directory: the entrypoint now writes to the `/config` mount (the container-side path of the `app_config` map) instead of an unmounted `/app_configs/cleanuparr` path, so Cleanuparr's data survives container recreation.
  
 ## 2.10.5 (2026-08-13)
 - Update to latest version from Cleanuparr/Cleanuparr (changelog : https://github.com/Cleanuparr/Cleanuparr/releases)

cleanuparr/Dockerfile

@@ -63,7 +63,7 @@ COPY bashio-standalone.sh /usr/local/lib/bashio-standalone.sh
 RUN chmod 0755 /usr/local/lib/bashio-standalone.sh
 
 # Bypass the original /entrypoint.sh (which mounts /config as VOLUME).
-# Our wrapper symlinks /app/config → HA addon_config and starts ./Cleanuparr directly.
+# Our wrapper symlinks /app/config → HA app_config and starts ./Cleanuparr directly.
 ENTRYPOINT ["/ha_entrypoint.sh"]
 CMD ["./Cleanuparr"]
 

cleanuparr/config.yaml

@@ -71,7 +71,7 @@ ingress_stream: true
 init: false
 panel_icon: mdi:movie-search
 map:
-  - addon_config:rw
+  - app_config:rw
 name: Cleanuparr
 options:
   env_vars: []

cleanuparr/rootfs/ha_entrypoint.sh

@@ -5,7 +5,7 @@ set -e
 ###############################################################################
 # Home Assistant Addon entrypoint for Cleanuparr
 # The .NET app uses /app/config as its data directory.
-# We symlink /app/config → /addon_configs/cleanuparr (HA persistent storage)
+# We symlink /app/config → /config (the HA app_config mount, HA persistent storage)
 # and start ./Cleanuparr directly, bypassing the original /entrypoint.sh
 # which would trigger the /config Docker VOLUME mount.
 ###############################################################################
@@ -26,7 +26,7 @@ if [ -d /etc/cont-init.d ]; then
 fi
 
 # ─── Setup persistent data directory ─────────────────────────────────────────
-HA_DATA_DIR="/addon_configs/cleanuparr"
+HA_DATA_DIR="/config"
 echo "[Cleanuparr] Setting up data directory: $HA_DATA_DIR"
 mkdir -p "$HA_DATA_DIR"
 

cloudcommander/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 19.20.5 (2026-09-05)
 - Update to latest version from coderaiser/cloudcmd (changelog : https://github.com/coderaiser/cloudcmd/releases)
@@ -234,7 +235,7 @@
 ## 16.17.7-3 (2023-11-19)
 
 - Minor bugs fixed
-- MAJOR CHANGE : new HA config logic implemented. Files are now located in the addon config file, that can be accessed from the addon_configs folder from my cloudcommander or cloudcommander addons. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
+- MAJOR CHANGE : new HA config logic implemented. Files are now located in the addon config file, that can be accessed from the app_configs folder from my cloudcommander or cloudcommander addons. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
 - Homeassistant config accessible in /homeassistant folder ; all addons config in /addons_config ; this addon config in /config
 
 ## 16.17.7-2 (2023-10-30)

cloudcommander/config.yaml

@@ -69,8 +69,8 @@ image: ghcr.io/alexbelgium/cloudcommander-{arch}
 ingress: true
 ingress_stream: true
 map:
-  - addon_config:rw
-  - all_addon_configs:rw
+  - app_config:rw
+  - all_app_configs:rw
   - homeassistant_config:rw
   - ssl:rw
   - share:rw

cloudcommander/rootfs/etc/cont-init.d/99-run.sh

@@ -35,7 +35,7 @@ fi
 # Create symlinks with legacy folders
 if [ -d /homeassistant/addons_config ]; then
     ln -s /homeassistant/addons_config /config
-    find /addon_configs/ -maxdepth 1 -mindepth 1 -type d -not -name "*cloudcommander*" -exec ln -s {} /config/addons_config/ \;
+    find /app_configs/ -maxdepth 1 -mindepth 1 -type d -not -name "*cloudcommander*" -exec ln -s {} /config/addons_config/ \;
 fi
 if [ -d /homeassistant/addons_autoscripts ]; then
     ln -s /homeassistant/addons_autoscripts /config

codex/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 2.2.11 (2026-08-29)
 - Update to latest version from ajslater/codex (changelog : https://github.com/ajslater/codex/releases)

codex/README.md

@@ -91,7 +91,7 @@ cifsdomain: "WORKGROUP"
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

codex/config.yaml

@@ -65,7 +65,7 @@ image: ghcr.io/alexbelgium/codex-{arch}
 ingress: true
 ingress_stream: true
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
 name: Codex

collabora/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 26.04.3.2.1 (2026-09-05)
 - Update to latest version from collabora/code

collabora/README.md

@@ -138,7 +138,7 @@ The two hostnames have different roles, and swapping them is the most common cau
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

collabora/config.yaml

@@ -8,7 +8,7 @@ environment:
 image: ghcr.io/alexbelgium/collabora-{arch}
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - ssl:ro
 name: Collabora
 options:

comixed/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 - Added support for configuring extra environment variables via the `env_vars` add-on option alongside config.yaml. See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.
 
 ## 1.3 (2024-03-11)

comixed/config.yaml

@@ -59,7 +59,7 @@ hassio_api: true
 homeassistant_api: true
 image: ghcr.io/alexbelgium/comixed-{arch}
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
   - share:rw
 name: Comixed

emby/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 
 ## 4.9.5.0 (2026-05-19)
 - Update to latest version from linuxserver/docker-emby (changelog : https://github.com/linuxserver/docker-emby/releases)
@@ -14,7 +15,7 @@
 ## 4.8.11.0-2 (2025-08-02)
 - Minor bugs fixed
 ## 4.8.11.0 (2025-04-22)
-- WARNING : migration of config to addon_config instead of homeassistant config folder. Allows automatic backups. The location of the database however is not changed.
+- WARNING : migration of config to app_config instead of homeassistant config folder. Allows automatic backups. The location of the database however is not changed.
 
 ## 4.9.0.48 (2025-04-19)
 - Update to latest version from linuxserver/docker-emby (changelog : https://github.com/linuxserver/docker-emby/releases)

emby/config.yaml

@@ -79,7 +79,7 @@ ingress_port: 0
 ingress_stream: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - share:rw
   - media:rw
   - ssl:rw

emby_beta/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 4.10.0.30 (2026-09-05)
 - Update to latest version from linuxserver/docker-emby (changelog : https://github.com/linuxserver/docker-emby/releases)
@@ -172,7 +173,7 @@
 ## 4.9.0.50 (2025-04-26)
 
 - Update to latest version from linuxserver/docker-emby (changelog : https://github.com/linuxserver/docker-emby/releases)
-- WARNING : migration of config to addon_config instead of homeassistant config folder. Allows automatic backups. The location of the database however is not changed.
+- WARNING : migration of config to app_config instead of homeassistant config folder. Allows automatic backups. The location of the database however is not changed.
 
 ## 4.9.0.48 (2025-04-19)
 

emby_beta/config.yaml

@@ -79,7 +79,7 @@ ingress_port: 0
 ingress_stream: true
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - homeassistant_config:rw
   - share:rw
   - media:rw

ente/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 4.4.27 (2026-09-05)
 - Update to latest version from ente/ente (changelog : https://github.com/ente/ente/releases)

ente/README.md

@@ -79,7 +79,7 @@ TZ: "America/New_York"
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

ente/config.yaml

@@ -76,7 +76,7 @@ environment:
 image: ghcr.io/alexbelgium/ente-{arch}
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
 name: Ente
 options:
   env_vars: []

filebrowser/CHANGELOG.md

@@ -1,3 +1,5 @@
+- Breaking change : only appears in ingress for admins
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 2.63.23 (2026-08-01)
 - Update to latest version from filebrowser/filebrowser (changelog : https://github.com/filebrowser/filebrowser/releases)
@@ -241,7 +243,7 @@
 
 ## 2.23.0_reverted5 (2023-11-21)
 
-- MAJOR CHANGE : new HA config logic implemented. Files are now located in the addon config file, that can be accessed from the addon_configs folder from my filebrowser or cloudcommander addons. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
+- MAJOR CHANGE : new HA config logic implemented. Files are now located in the addon config file, that can be accessed from the app_configs folder from my filebrowser or cloudcommander addons. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
 - Homeassistant config accessible in /homeassistant folder ; all addons config in /addons_config ; this addon config in /config
 
 ## 2.23.0_reverted (2023-09-29)

filebrowser/README.md

@@ -108,7 +108,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

filebrowser/config.yaml

@@ -81,9 +81,9 @@ ingress_entry: files
 ingress_port: 8071
 ingress_stream: true
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
-  - all_addon_configs:rw
+  - all_app_configs:rw
   - homeassistant_config:rw
   - addons:rw
   - backup:rw
@@ -98,7 +98,7 @@ options:
   follow_external_symlinks: true
   keyfile: privkey.pem
   ssl: false
-panel_admin: false
+panel_admin: true
 panel_icon: mdi:file-search
 ports:
   8080/tcp: 8071

filebrowser/rootfs/etc/cont-init.d/20-folders.sh

@@ -35,7 +35,7 @@ fi
 # Create symlinks with legacy folders
 if [ -d /homeassistant/addons_config ]; then
     ln -s /homeassistant/addons_config /config
-    find /addon_configs/ -maxdepth 1 -mindepth 1 -type d -not -name "*filebrowser*" -exec ln -s {} /config/addons_config/ \;
+    find /app_configs/ -maxdepth 1 -mindepth 1 -type d -not -name "*filebrowser*" -exec ln -s {} /config/addons_config/ \;
 fi
 if [ -d /homeassistant/addons_autoscripts ]; then
     ln -s /homeassistant/addons_autoscripts /config

filebrowser_quantum/CHANGELOG.md

@@ -1,3 +1,5 @@
+- Breaking change : only appears in ingress for admins
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 1.5.6 (2026-09-05)
 - Update to latest version from gtsteffaniak/filebrowser (changelog : https://github.com/gtsteffaniak/filebrowser/releases)

filebrowser_quantum/README.md

@@ -85,7 +85,7 @@ This addon supports mounting both local drives and remote SMB shares:
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-add-ons

filebrowser_quantum/config.yaml

@@ -82,9 +82,9 @@ ingress: true
 ingress_port: 8071
 ingress_stream: true
 map:
-  - addon_config:rw
+  - app_config:rw
   - media:rw
-  - all_addon_configs:rw
+  - all_app_configs:rw
   - homeassistant_config:rw
   - addons:rw
   - backup:rw
@@ -95,7 +95,7 @@ options:
   env_vars: []
   auth_method: noauth
   default_user_scope: "/"
-panel_admin: false
+panel_admin: true
 panel_icon: mdi:file-search
 ports:
   8072/tcp: 8071

fireflyiii_data_importer/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 2.3.4 (2026-07-04)
 - Update to latest version from firefly-iii/data-importer (changelog : https://github.com/firefly-iii/data-importer/releases)
@@ -193,7 +194,7 @@
 
 ## 1.4.5-2 (2024-03-28)
 
-- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/fireflyiii_date_importer in a folder only accessible from my Filebrowser addon called /addon_configs/db21ed7f_fireflyiii_date_importer. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
+- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration files will have migrated from /config/hassio_addons/fireflyiii_date_importer in a folder only accessible from my Filebrowser addon called /app_configs/db21ed7f_fireflyiii_date_importer. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration of data, custom configs, and custom scripts should be automatic. Please be sure to update all your links however ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
 
 ## 1.4.5 (2024-03-23)
 

fireflyiii_data_importer/README.md

@@ -78,11 +78,11 @@ silent: false
 
 ### File Locations
 
-- **Configurations**: `/addon_configs/xxx-fireflyiii_data_importer/configurations/`
+- **Configurations**: `/app_configs/xxx-fireflyiii_data_importer/configurations/`
   - Store import configuration files here
   - See: https://docs.firefly-iii.org/data-importer/help/config/
 
-- **Import Files**: `/addon_configs/xxx-fireflyiii_data_importer/import_files/`
+- **Import Files**: `/app_configs/xxx-fireflyiii_data_importer/import_files/`
   - Place CSV files here for automatic importing
   - See: https://docs.firefly-iii.org/data-importer/usage/command_line/
 
@@ -95,7 +95,7 @@ silent: false
 
 ### Custom Scripts and Environment Variables
 
-This addon supports custom scripts and environment variables through the `addon_config` mapping:
+This addon supports custom scripts and environment variables through the `app_config` mapping:
 
 - **Custom scripts**: See [Running Custom Scripts in Addons](https://github.com/alexbelgium/hassio-addons/wiki/Running-custom-scripts-in-Addons)
 - **env_vars option**: Use the add-on `env_vars` option to pass extra environment variables (uppercase or lowercase names). See https://github.com/alexbelgium/hassio-addons/wiki/Add-Environment-variables-to-your-Addon-2 for details.

fireflyiii_data_importer/config.yaml

@@ -69,7 +69,7 @@ environment:
 image: ghcr.io/alexbelgium/fireflyiii_data_importer-{arch}
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - homeassistant_config:rw
   - share:rw
   - ssl

free_games_claimer/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
 ## 2.1.0 (2026-08-24)
 
 - Updated the pinned upstream from Free Games Claimer Remaster 1.1 to 1.6,

free_games_claimer/README.md

@@ -71,7 +71,7 @@ scheduler. Set `SCHEDULER_HOURS` in `config.env` to control the interval.
 
 The add-on keeps its configuration in `CONFIG_LOCATION`, which defaults to
 `/config/config.env`. From Home Assistant this is stored in the add-on's
-private `addon_configs` directory and can be edited with a compatible file
+private `app_configs` directory and can be edited with a compatible file
 browser add-on.
 
 A template is created on first start. Common examples are:

free_games_claimer/config.yaml

@@ -70,7 +70,7 @@ environment:
 image: ghcr.io/alexbelgium/free_games_claimer-{arch}
 init: false
 map:
-  - addon_config:rw
+  - app_config:rw
   - homeassistant_config:rw
 name: Free Games Claimer
 options:

free_games_claimer/rootfs/etc/cont-init.d/00-migrate_files.sh

@@ -5,7 +5,7 @@ slug="free_games_claimer"
 if [ -f "/homeassistant/addons_config/$slug/config.yaml" ] && [ ! -f "/homeassistant/addons_config/$slug/migrated" ]; then
     bashio::log.warning "Migrating config.yaml"
     mv "/homeassistant/addons_config/$slug"/* /config/ || true
-    echo "Migrated to internal config folder accessible at /addon_configs/xxx-$slug" > "/homeassistant/addons_config/$slug/migrated"
+    echo "Migrated to internal config folder accessible at /app_configs/xxx-$slug" > "/homeassistant/addons_config/$slug/migrated"
 fi
 
 if [ -f "/homeassistant/addons_autoscripts/$slug.sh" ]; then

gitea/CHANGELOG.md

@@ -1,3 +1,4 @@
+- Migrate legacy add-on configuration map names to current app configuration terminology.
  
 ## 1.27.3 (2026-09-05)
 - Update to latest version from go-gitea/gitea (changelog : https://github.com/go-gitea/gitea/releases)
@@ -19,7 +20,7 @@
 - Minor bugs fixed
 
 ## 1.26.2-2 (2026-06-19)
-- Expose app.ini in the addon_config folder so users can edit it directly via the HA file editor
+- Expose app.ini in the app_config folder so users can edit it directly via the HA file editor
 
 ## 1.26.2-1 (2026-06-19)
 - Fix SSH authentication failing with `chroot("/var/empty"): Operation not permitted [preauth]` by allowing `capability sys_chroot` in the AppArmor profile, which sshd needs for privilege-separation (#2653)