diff --git a/containers/127-mule-photos-new.md b/containers/127-mule-photos-new.md
index e7f648d..1af926a 100644
--- a/containers/127-mule-photos-new.md
+++ b/containers/127-mule-photos-new.md
@@ -146,6 +146,37 @@ curl -sk --resolve photos-new.hubris.network:443:192.168.8.175 \
 
 ## Changelog
 
+### 2026-05-18 (pm) — OIDC state-cookie fix: deploy.sh no longer recreates pp-app
+
+User reported `failed to get state: securecookie: the value is not valid` after
+authenticating at Authentik. Root cause: PhotoPrism rotates the `Session:` HMAC
+key in `pp/storage/config/hub.yml` on **every container start** (it's the hub
+auto-refresh; no env flag disables it, and with `Status: ""` it regenerates
+each boot). The key signs OIDC state cookies, so every restart invalidated
+every in-flight login.
+
+`/opt/mule-deploy/deploy.sh` was doing `docker compose up -d --build
+--force-recreate` after a `pull --ignore-buildable`. Both moves recreate
+pp-app: `--force-recreate` unconditionally, and the pull bumps the
+`photoprism:latest` digest which makes plain `up -d` recreate too. Every
+auto-deploy on a code push therefore broke every OIDC login.
+
+Fixed by:
+
+1. Dropping the `pull` step from the auto-deploy. Image refreshes for pp-app
+   / mariadb are now an admin operation (run `docker compose pull` manually
+   when you want a new PhotoPrism build).
+2. Force-recreating only the **sidecar** (its image rebuilds on every push
+   anyway). `up -d photoprism mariadb` reconciles in place — only restarts
+   if their compose declaration actually changes.
+
+Verified by running `deploy.sh` twice and watching `hub.yml`'s `Session:`
+field and pp-app's container PID; both stayed stable across the deploy.
+The sidecar's PID changed as expected.
+
+The fix lives in `/opt/mule-deploy/deploy.sh` on LXC 127. `/opt/mule-deploy`
+is not a git checkout — keep this Changelog entry as the source of truth.
+
 ### 2026-05-18 — OIDC bridge + indexer + folder fixes
 
 The `new` branch's PhotoPrism stack required several iterations to be