Refresh expired StepFun tokens

[LeoLin990405]

Summary

• Add StepFun RefreshToken support and retry usage once after auth failures
• Persist refreshed tokens back to token accounts in the app and CLI paths
• Keep username/password login fallback for non-manual auth and improve StepFun auth error guidance

Testing

• swift build --target CodexBarCore
• swift build --product CodexBarCLI
• swift run CodexBarCLI usage --provider stepfun --format json --pretty --no-color
• swift test --filter StepFun (blocked locally: test build fails before StepFun tests because Command Line Tools cannot build the existing Swift Testing/preview-macro test targets)

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed May 26, 2026, 5:35 AM ET / 09:35 UTC.

Summary
The branch adds StepFun RefreshToken calls, retries usage once after auth failures, persists refreshed token-account values in app and CLI paths, and adds StepFun refresh tests.

Reproducibility: no. high-confidence live reproduction is included. Source inspection shows current main does not refresh manual StepFun Oasis-Token auth failures, while the PR adds stubbed coverage for that path.

Review metrics: 2 noteworthy metrics.

• Changed surface: 5 files, +480/-25. The production change spans core StepFun auth and CLI token persistence, while most added lines are targeted tests.
• Credential persistence paths: 2 runtime paths touched. Refreshed tokens may now be written through app context and CLI config paths, so upgrade behavior matters before merge.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Add redacted output or a terminal screenshot showing the StepFun expired-token refresh and retry succeeding in a real setup.
• Report make check and the focused StepFun tests, or explain the local toolchain blocker after retrying.

Proof guidance:
Needs stronger real behavior proof before merge: The PR body lists a live CLI command but no output or logs showing expired-token refresh; contributor should add redacted terminal output or a screenshot/recording and update the PR body for re-review, or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• No attached redacted output or logs prove the live StepFun RefreshToken endpoint accepts the combined Oasis token and that the retry/persist path works after an expired token.
• Repository validation is incomplete relative to AGENTS.md: make check is not reported and the focused StepFun test run was blocked before these tests.
• The patch changes credential persistence for StepFun token accounts; maintainers should confirm this is intended for manual token accounts and CLI config writes.

Maintainer options:

1. Require redacted StepFun refresh proof (recommended)
   Ask the contributor to update the PR body with terminal output, logs, or a screenshot/recording showing an expired StepFun token refreshes, usage retries successfully, and persisted token values are redacted.
2. Accept service-endpoint uncertainty
   Maintainers can merge based on source review and stubbed tests if they are comfortable owning the live StepFun RefreshToken behavior without contributor proof.
3. Pause for API confirmation
   If the RefreshToken request shape is uncertain, pause the PR until the StepFun endpoint contract is confirmed or covered by a narrow live-proof note.

Next step before merge
Contributor or maintainer action is needed for redacted real StepFun behavior proof and repository validation; there is no narrow code repair for ClawSweeper to make from this review.

Security
Cleared: No concrete security or supply-chain regression was found; the diff uses existing StepFun endpoints and existing token-account persistence seams without new dependencies or workflow changes.

Review details

Best possible solution:

Land the refresh path after redacted live StepFun proof shows expired-token refresh, one retry succeeds, and app/CLI token persistence works, with make check and relevant tests passing or clearly explained.

Do we have a high-confidence way to reproduce the issue?

No high-confidence live reproduction is included. Source inspection shows current main does not refresh manual StepFun Oasis-Token auth failures, while the PR adds stubbed coverage for that path.

Is this the best way to solve the issue?

Unclear until live proof is added. The implementation direction matches the existing token-account updater model, but the live StepFun refresh endpoint and persistence behavior need redacted real-run evidence before it is clearly the best fix.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against bba645336d3c.

Label changes

Label changes:

• add P2: This is a normal-priority provider reliability fix with limited blast radius to StepFun auth and token-account persistence.
• add merge-risk: 🚨 auth-provider: The PR changes StepFun credential refresh, retry routing, and token persistence, and live endpoint behavior is not proven by tests alone.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body lists a live CLI command but no output or logs showing expired-token refresh; contributor should add redacted terminal output or a screenshot/recording and update the PR body for re-review, or ask a maintainer to comment @clawsweeper re-review.

Label justifications:

• P2: This is a normal-priority provider reliability fix with limited blast radius to StepFun auth and token-account persistence.
• merge-risk: 🚨 auth-provider: The PR changes StepFun credential refresh, retry routing, and token persistence, and live endpoint behavior is not proven by tests alone.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body lists a live CLI command but no output or logs showing expired-token refresh; contributor should add redacted terminal output or a screenshot/recording and update the PR body for re-review, or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Current main behavior: Current main retries StepFun API auth errors only when the cookie source is not manual; manual Oasis-Token failures have no refresh path, so the PR addresses a real missing StepFun recovery path. (Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swift:53, bba645336d3c)
• PR refresh path: The PR head adds authentication-failure recovery that calls StepFunUsageFetcher.refreshToken, persists recovered tokens, then retries usage with the refreshed token. (Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swift:135, 320e1367780d)
• PR token persistence path: The PR head adds CLI token-account persistence for refreshed tokens, complementing the existing app ProviderFetchContext updater path. (Sources/CodexBarCLI/TokenAccountCLI.swift:349, 320e1367780d)
• Live proof gap: The PR body lists a StepFun CLI usage command but does not include output, logs, screenshots, or other inspected proof showing an expired live token was refreshed and persisted; it also says the StepFun test run was blocked before these tests. (320e1367780d)
• Repository validation policy: AGENTS.md was read fully and asks for swift test plus make check after code changes; make check is not reported and the focused StepFun test run was blocked in the PR body. (AGENTS.md:24, bba645336d3c)
• Feature history: GitHub commit history for the touched StepFun files shows tevenfeng introduced the provider in c51ec0f; adjacent HTTP transport history includes steipete and serezha93. (Sources/CodexBarCore/Providers/StepFun/StepFunUsageFetcher.swift:211, c51ec0f56950)

Likely related people:

• tevenfeng: GitHub path history shows c51ec0f added the StepFun provider and its auth/usage files. (role: introduced StepFun provider; confidence: high; commits: c51ec0f56950; files: Sources/CodexBarCore/Providers/StepFun/StepFunProviderDescriptor.swift, Sources/CodexBarCore/Providers/StepFun/StepFunUsageFetcher.swift, Tests/CodexBarTests/StepFunUsageFetcherTests.swift)
• steipete: Recent commits and current blame touch provider HTTP transport, token account/CLI surfaces, and the release-squashed current StepFun files. (role: recent adjacent owner; confidence: high; commits: ad33b32773bd, 2f13f3e6610f, 333d584a4950; files: Sources/CodexBarCore/Providers/StepFun/StepFunUsageFetcher.swift, Sources/CodexBarCLI/TokenAccountCLI.swift, Sources/CodexBarCore/Providers/ProviderFetchPlan.swift)
• serezha93: The shared ProviderHTTPClient transport used by StepFun requests traces to the provider HTTP transport work in f62bb8c. (role: adjacent HTTP transport contributor; confidence: medium; commits: f62bb8c8d564; files: Sources/CodexBarCore/Providers/StepFun/StepFunUsageFetcher.swift, Tests/CodexBarTests/ProviderHTTPClientTests.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 320e136778

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Re-resolve auth without cached token after auth failure

After an authentication failure, this path calls resolveToken(..., allowCached: true) again, which reselects the cached token before trying STEPFUN_TOKEN (cache is checked earlier in resolveToken). In the common case where the cache is stale but STEPFUN_TOKEN is valid and no username/password is configured, recovery never attempts the valid env token and incorrectly fails with an auth error. Re-resolve with allowCached: false (or clear cache first) before fallback so non-cached credentials can be used.

Useful? React with 👍 / 👎.