Skip to content

feat(auth): share provider sign-in flows across clients - #12965

Merged
juliusmarminge merged 33 commits into
t3code/codex-turn-mappingfrom
provider-auth/foundation
Sep 22, 2026
Merged

juliusmarminge merged 33 commits into
t3code/codex-turn-mappingfrom
provider-auth/foundation

fix(provider-auth): copy sign-in links within the click; namespace se…

9922edc
Select commit
Loading
Failed to load commit list.
MacroscopeApp / Macroscope - Effect Service Conventions succeeded Sep 22, 2026 in 3m 5s

All clear

All clear

Details

Note

Your check run agent prompt is: .macroscope/check-run-agents/effect-service-conventions.md
More information about how Check Run Agents work can be found in our Help Center.

Reviewed 2 of 15 changed files — those modified since 49acdf0 — each against the merge base


🔍 Agent activity — 2 tool calls

1. browse_code — Review these two selected files for Effect Service Conventions only: apps/server/src/provider/Layers/ProviderAuthService.ts and apps/server/src/provider/ProviderAuthFlow.ts at current PR head. Check namespace imports, Effect dependency acquisition, service construction conventions, runtime boundaries, error conventions, and whether focused tests cover newly introduced shared-binding concurrency/invalidation and ProviderAuthFlow behavior. Return only concrete violations introduced in these files, with exact lines and supporting context. Do not treat callback strategies or immutable config as service injection.

💭 Evaluating code changes I need to be cautious about any changes to imports in existing code. The only modification is to the ProviderAuth import, while others remain untouched. I should examine the full diff, particularly looking for any additions related to failures. It seems that line 60 is likely affected by the filtering addition of affectedIds. I wonder if the tests sufficiently cover this backend behavior change or if I'll need to inspect them more closely.

2. browse_code — apps/server/src/provider/Layers/ProviderAuthService.test.ts

💭 Checking test structure I'm considering tests that cover a specific feature. There's a convention in place, but I’m not sure if that has resulted in any findings. The request asks for "All clear," but the structured format seems to conflict with that. I realize I need to have complete check fields but can't provide an exact response for each line. Maybe it’s possible to title or summarize as "All clear"? I'll focus on ensuring there are no comments in the response.


Agent Credits: 33 credits

Token usage: 24 uncached input · 93,388 cache-read input · 44,807 cache-write input · 2,306 output
Agent Credits may also include non-token charges from external tools such as web research.