Summary
The GitHub OAuth login flow and the GitHub follow integration appear to share the same persisted GitHub credential storage without preserving required scopes.
As a result, users who previously connected GitHub for follow functionality can silently lose follow capability after later authenticating through the normal GitHub login flow.
This creates persistent cross-feature state corruption that is difficult to detect because both flows work independently in isolation.
Affected Areas
apps/backend/src/routes/auth.tsapps/backend/src/routes/connect.ts- GitHub follow integration logic
- GitHub token persistence/update flow
Root Cause
The platform-connect flow stores GitHub OAuth tokens with follow-capable scopes.
Later, the standard GitHub login/authentication flow appears to overwrite the existing stored GitHub token record using a newly-issued OAuth token that may not contain the same scopes.
Because the overwrite is silent and unconditional:
- the original follow-capable token is lost
- persisted integration state becomes corrupted
- GitHub follow functionality breaks until the user reconnects manually
The issue is subtle because:
- login itself still succeeds
- connected-account state may still appear valid
- no immediate validation detects the scope downgrade
Example Failure Flow
- User connects GitHub through the platform-connect flow
- Backend stores a token with follow-required scopes
- Follow functionality works normally
- User later signs in again through standard GitHub OAuth login
- Auth flow overwrites the stored GitHub token
- New token lacks follow-required scopes
- GitHub follow functionality silently fails afterward
Why This Is Difficult To Detect
Current tests validate flows independently:
- login flow works
- connect flow works
- follow flow works with valid scopes
However, there does not appear to be integration coverage validating:
- cross-flow token persistence invariants
- scope preservation during token replacement
- multi-flow credential lifecycle behavior
This creates a production-only state corruption issue hidden by isolated route testing.
Production Impact
Users can permanently lose GitHub follow capability simply by logging in again.
Potential impact includes:
- failed follow automation
- inconsistent connected-account state
- broken onboarding assumptions
- silent permission downgrades
- difficult-to-debug user reports
Proposed Fix
Possible approaches include:
Option 1 — Separate Token Storage
Store:
- authentication/login tokens
- integration/follow tokens
independently.
Option 2 — Scope Preservation
Before overwriting an existing GitHub token:
- validate existing scopes
- preserve higher-privilege tokens
- or merge token metadata safely
Option 3 — Explicit Reauthorization
If a new token lacks required scopes:
- reject overwrite
- or require explicit reconnect flow
Acceptance Criteria
- GitHub login cannot silently break follow integrations
- follow-capable scopes remain preserved
- token overwrites are validated safely
- reconnect state remains consistent
- regression coverage added for cross-flow credential lifecycle behavior
Severity
High
This creates long-lived persistent integration corruption across independently-correct OAuth flows and affects core GitHub integration behavior in production.
Summary
The GitHub OAuth login flow and the GitHub follow integration appear to share the same persisted GitHub credential storage without preserving required scopes.
As a result, users who previously connected GitHub for follow functionality can silently lose follow capability after later authenticating through the normal GitHub login flow.
This creates persistent cross-feature state corruption that is difficult to detect because both flows work independently in isolation.
Affected Areas
apps/backend/src/routes/auth.tsapps/backend/src/routes/connect.tsRoot Cause
The platform-connect flow stores GitHub OAuth tokens with follow-capable scopes.
Later, the standard GitHub login/authentication flow appears to overwrite the existing stored GitHub token record using a newly-issued OAuth token that may not contain the same scopes.
Because the overwrite is silent and unconditional:
The issue is subtle because:
Example Failure Flow
Why This Is Difficult To Detect
Current tests validate flows independently:
However, there does not appear to be integration coverage validating:
This creates a production-only state corruption issue hidden by isolated route testing.
Production Impact
Users can permanently lose GitHub follow capability simply by logging in again.
Potential impact includes:
Proposed Fix
Possible approaches include:
Option 1 — Separate Token Storage
Store:
independently.
Option 2 — Scope Preservation
Before overwriting an existing GitHub token:
Option 3 — Explicit Reauthorization
If a new token lacks required scopes:
Acceptance Criteria
Severity
High
This creates long-lived persistent integration corruption across independently-correct OAuth flows and affects core GitHub integration behavior in production.