fix(status): honor selected usage auth profile#59208
Conversation
Greptile SummaryThis PR fixes a status card consistency bug where the OAuth auth label and the usage/quota line could resolve credentials from different profiles when multiple OAuth profiles existed for the same provider. The fix threads
Confidence Score: 5/5
Prompt To Fix All With AIThis is a comment left during a code review.
Path: src/infra/provider-usage.auth.ts
Line: 32-34
Comment:
**Redundant normalization in `normalizeProfileProvider`**
`normalizeProviderId` already calls `.trim().toLowerCase()` internally (see `provider-id.ts` line 2: `const normalized = provider.trim().toLowerCase()`). The chained `.trim().toLowerCase()` on the return value is a no-op in every case, since `normalizeProviderId` always returns an already-trimmed, lowercased string.
```suggestion
function normalizeProfileProvider(value: string | undefined): string {
return normalizeProviderId(value ?? "");
}
```
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix(status): validate preferred oauth pr..." | Re-trigger Greptile |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 69a0f32071
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
Codex review: needs real behavior proof before merge. Reviewed May 24, 2026, 2:42 PM ET / 18:42 UTC. Summary PR surface: Source +27, Tests +97. Total +124 across 6 files. Reproducibility: yes. at source level: current main displays the selected session auth profile but usage auth resolution still follows provider order without that preferred profile. I did not establish a live two-profile OAuth reproduction in this read-only review. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance: Risk before merge
Maintainer options:
Next step before merge Security Review detailsBest possible solution: Land the focused preferred-profile threading after redacted credential/account-level proof is added, or after a maintainer explicitly accepts the remaining live OAuth proof gap; keep the linked issue open until this PR merges. Do we have a high-confidence way to reproduce the issue? Yes at source level: current main displays the selected session auth profile but usage auth resolution still follows provider order without that preferred profile. I did not establish a live two-profile OAuth reproduction in this read-only review. Is this the best way to solve the issue? Mostly yes: threading a validated preferred profile through provider usage auth is the narrow maintainable fix, and the provider-match guard preserves fallback behavior. The remaining blocker is diagnostic real behavior proof, not a concrete code-shape defect. Codex review notes: model gpt-5.5, reasoning high; reviewed against dfa1a5122584. Label changesLabel justifications:
Evidence reviewedPR surface: Source +27, Tests +97. Total +124 across 6 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
fix some conficts |
38fe84d to
b057f04
Compare
|
Pushed the rebased maintainer-ready version onto this contributor branch and kept the changelog credit merged. Verification already run on the pushed head
|
|
Pushed the rebased maintainer-ready version onto this contributor branch and kept the changelog credit merged. Verification already run on the pushed head :
RUN v4.1.5 /Users/vincentkoc/GIT/_Perso/openclaw Test Files 1 passed (1)
All matched files use the correct format.
No guarded extension wildcard re-exports found.
No plugin-sdk wildcard re-exports found in extension API barrels.
[dup:check] target coverage ok exit 0 |
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
@vincentkoc Thanks for rebasing and verifying the pushed head. From my side this looks ready now. Could a maintainer confirm whether any additional real-behavior proof is still needed, or if this can move to final review/merge? Posting an update to keep this from going stale. |
Thread preferredProfileIds through provider auth resolution so the status command uses the user-selected auth profile instead of always falling back to the default ordering. - Add preferredProfileIds param to resolveProviderAuths and plumb through plugin, fallback, and OAuth resolution paths - Pass session authProfileOverride from status-text to usage loader - Re-export tryReadSecretFileSync directly from @openclaw/fs-safe/secret - Fix lint violations (no-useless-fallback-in-spread) and type errors Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
d89265e to
4b6c78d
Compare
f2aa61c to
4b6c78d
Compare
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
@clawsweeper status |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
This assigned pull request has been automatically marked as stale after being open for 27 days. |
|
Closing due to inactivity. |
|
I don't think that was fixed, I'm using the version 2026.5.6 and this issue still appearing. I have two oauth providers, and it's showing the wrong usage when I change them. @vincentkoc , @luoxiao6645 feel free to revive that. 👍 |
|
@peetorres The boat had closed my PR,The maintainers didn't pay attention to this issue and didn't merge it. I don't know what's going on. |
Summary
/statusalready usedsessionEntry.authProfileOverridefor the auth label.Root cause
The status surface had two different auth-selection paths:
That split made the status card internally inconsistent for multi-profile OAuth setups.
Real behavior proof (required for external PRs)
Behavior or issue addressed:
/statuscould show one OAuth profile as active while the usage/quota line reflected a different OAuth profile under the same provider.Real environment tested:
Local OpenClaw development setup with multiple OAuth profiles configured for the same provider and a session-level
authProfileOverrideselecting a non-default profile.Exact steps or command run after this patch:
authProfileOverride./status.Evidence after fix:
Copied live output from a local
/statusrun after the patch:In this after-fix output, the auth label and the usage-backed status line both resolve through the same selected OAuth profile.
Observed result after fix:
After the patch,
/statusused the same session-selected OAuth profile for both the auth label and the usage/quota line. A stale or cross-provider preferred profile was ignored and fell back to the existing provider-scoped order.What was not tested:
I did not run a full provider-by-provider matrix or remote deployment verification. I focused on the affected multi-profile OAuth status flow.
Regression coverage
src/infra/provider-usage.auth.normalizes-keys.test.tssrc/infra/provider-usage.load.test.tssrc/agents/openclaw-tools.session-status.test.ts