Problem
GitHub App user-to-server tokens expire (8h by default) and are issued with a refresh_token, unless the App opts out of token expiration in its own settings. AMS runs can genuinely last longer than 8h. Without refresh handling, a long-running AMS loop authenticated via this flow would start failing mid-run once the token expires.
Area
src/auth/github-oauth.ts / wherever #[persist-token issue] ends up storing the token.
Proposal
Two real options, not a foregone conclusion — decide before building:
- Store and use the
refresh_token GitHub issues alongside the access token, and transparently refresh when the stored token is near/past expiry (check the actual GitHub token-exchange response shape for expires_in/refresh_token/refresh_token_expires_in — confirm these are actually present in this App's token responses before assuming the shape).
- Turn off token expiration in the Loopover ORB App's settings (GitHub Apps support this as a toggle) — simpler to build (no refresh logic at all), but a non-expiring, long-lived, full-write-access token is a bigger blast radius if it ever leaks, and is a real security tradeoff, not just an implementation-effort one.
Recommend evaluating both against this repo's existing risk posture (compare to how the App's own installation tokens are already handled/rotated) before picking one — this issue's first deliverable is that decision, not just the implementation.
Deliverables
Resources
- #[persist-token issue] (this issue is blocked by it — needs somewhere to store the refresh_token too, if that path is chosen)
- GitHub Apps' token-expiration opt-out setting (App settings, not code)
Boundaries
Security-sensitive tradeoff, not a routine implementation choice — the option-1-vs-2 decision should get a real second look before committing, given the blast-radius difference. Maintainer-only for now.
maintainer-only — assigned JSONbored.
Problem
GitHub App user-to-server tokens expire (8h by default) and are issued with a
refresh_token, unless the App opts out of token expiration in its own settings. AMS runs can genuinely last longer than 8h. Without refresh handling, a long-running AMS loop authenticated via this flow would start failing mid-run once the token expires.Area
src/auth/github-oauth.ts/ wherever #[persist-token issue] ends up storing the token.Proposal
Two real options, not a foregone conclusion — decide before building:
refresh_tokenGitHub issues alongside the access token, and transparently refresh when the stored token is near/past expiry (check the actual GitHub token-exchange response shape forexpires_in/refresh_token/refresh_token_expires_in— confirm these are actually present in this App's token responses before assuming the shape).Recommend evaluating both against this repo's existing risk posture (compare to how the App's own installation tokens are already handled/rotated) before picking one — this issue's first deliverable is that decision, not just the implementation.
Deliverables
Resources
Boundaries
Security-sensitive tradeoff, not a routine implementation choice — the option-1-vs-2 decision should get a real second look before committing, given the blast-radius difference. Maintainer-only for now.
maintainer-only — assigned JSONbored.