The app service's environment: block in docker-compose.yml is an explicit allow-list — its own comment says so:
# Optional. This block is an explicit allow-list, not env_file — a var
# added to .env but not listed here never reaches the container.
#20 added OIDC_OFFLINE_ACCESS to .env.example and the README but missed this file. Setting it in .env would have been silently ignored — the server would keep advertising the old scope list, and the natural conclusion would have been that the Authentik-side change had failed.
One line, matching the existing pattern for OIDC_ISSUER_MCP / OIDC_AUDIENCE_SCOPE.
The docker-compose.external-db.yml override merges its environment block rather than replacing it (no !override on that key), so it inherits this automatically and needs no equivalent change.
Verified post-deploy by checking the variable is actually present in the running container's environment.
Follow-up to #20, caught during deploy.
The app service's `environment:` block in `docker-compose.yml` is an explicit allow-list — its own comment says so:
> ```
> # Optional. This block is an explicit allow-list, not env_file — a var
> # added to .env but not listed here never reaches the container.
> ```
#20 added `OIDC_OFFLINE_ACCESS` to `.env.example` and the README but missed this file. Setting it in `.env` would have been **silently ignored** — the server would keep advertising the old scope list, and the natural conclusion would have been that the Authentik-side change had failed.
One line, matching the existing pattern for `OIDC_ISSUER_MCP` / `OIDC_AUDIENCE_SCOPE`.
The `docker-compose.external-db.yml` override merges its `environment` block rather than replacing it (no `!override` on that key), so it inherits this automatically and needs no equivalent change.
Verified post-deploy by checking the variable is actually present in the running container's environment.
The app service's environment block is an explicit allow-list, not
env_file — as the comment two lines above this change says, a var added
to .env but not listed here never reaches the container.
PR #20 added OIDC_OFFLINE_ACCESS to .env.example and documented it in the
README but missed this, so setting it in .env would have been silently
ignored and the refresh-token fix would not have taken effect. Caught
while deploying, before it could look like the IdP change had failed.
The external-db override merges its environment block rather than
replacing it, so it inherits this and needs no equivalent change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jknapp
merged commit 80341c558d into main2026-08-11 22:29:19 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Follow-up to #20, caught during deploy.
The app service's
environment:block indocker-compose.ymlis an explicit allow-list — its own comment says so:#20 added
OIDC_OFFLINE_ACCESSto.env.exampleand the README but missed this file. Setting it in.envwould have been silently ignored — the server would keep advertising the old scope list, and the natural conclusion would have been that the Authentik-side change had failed.One line, matching the existing pattern for
OIDC_ISSUER_MCP/OIDC_AUDIENCE_SCOPE.The
docker-compose.external-db.ymloverride merges itsenvironmentblock rather than replacing it (no!overrideon that key), so it inherits this automatically and needs no equivalent change.Verified post-deploy by checking the variable is actually present in the running container's environment.