Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
clawsweeper
Bot
added
P2
|
Codex review: needs real behavior proof before merge. Reviewed September 25, 2026, 3:58 PM ET / 19:58 UTC. ClawSweeper reviewWhat this changesAdds an opt-in browser-session fallback that reads Muse Code subscription quotas when the CLI login response omits them, with settings, documentation, and tests. Merge readiness⛔ Blocked before merge - 7 items remain This PR addresses a real gap in Muse Code quota display and has useful live CLI evidence. It needs a team-identity repair and provider-privacy sign-off before merge. Priority: P2 Review scores
Verification
How this fits togetherCodexBar reads Muse Code usage through a bundled provider plugin. The plugin normally uses a CLI device token; this branch also lets it use a browser session to fill missing quota windows before the app or CLI displays them. flowchart LR
A[Muse CLI login] --> B[Subscription response]
B --> C{Quotas present?}
C -->|Yes| F[Usage display]
C -->|No| D[Opt-in browser session]
D --> E[Account and team quota checks]
E --> F
Decision needed
Why: This adds a provider credential path governed by the repository's privacy and authentication sign-off policy. Before merge
Findings
Agent review detailsSecurityNeeds attention: The new browser credential path checks account email, but does not establish which subscribed team may supply the displayed quota. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Bind the web quota to the CLI subscription's team, or fail closed when that binding is ambiguous; retain the opt-in default and obtain approval for browser-session access. Do we have a high-confidence way to reproduce the issue? Yes for the reported idle-window gap: the linked issue and live CLI trace show missing quota on the released build. The multi-team misassociation follows from the introduced first-match selection and still needs a final-path demonstration. Is this the best way to solve the issue? Unclear. An opt-in fallback fits the existing plugin architecture, but team identity must be resolved before the displayed quota can be trusted. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against a2cf7face10b. LabelsLabel changes:
Label justifications:
EvidenceSecurity concerns:
What I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
|
Thanks @enieuwy for the implementation and redacted trace. The opt-in default and domain/credential scoping are sound. Closing this version because matching account emails does not identify the subscription: the plugin accepts the first team with a quota and labels it as the CLI plan with exact confidence. A synthetic check changes the displayed weekly usage from 10% to 80% solely by reversing team order; the submitted fixture also accepts an Everyday quota under a Power login. The missing quota still needs a reliable data source, so this is not being closed as unnecessary or already fixed. If you want to take another pass: an explicit, user-selected team (an opt-in setting listing the teams the session can see, no first-match) labeled as a browser-team quota rather than as the CLI plan would be adoptable with the same domain scoping; keep the present/omitted/expired-window fixtures on both engines and add wrong-team and list-order cases. |
|
Superseded by #4011, which landed the reworked explicit team selection. Closing this earlier version. |
2 participants
Summary
Fixes #4002.
While the Muse Code 5-hour window is idle,
POST /muse-code/keyomitssubs_usage, so CodexBar (and the Muse CLI/usage) show no quota even when the weekly limit has real usage. This adds an opt-in fallback inside the existing bundledmuse.tsplugin: when — and only when — the login response omitssubs_usage, it reads the same quota thedev.meta.ai/usagepage shows, using the browser session for the same account.No new provider, no new plugin-host capability, no browser automation.
Behavior
/muse-code/keystill runs first and still wins. If it containssubs_usage, nodev.meta.airequest is made.GET /api/auth/me— the session email must equal the CLI login'suser_email, or no web quota is used.GET /api/portal/teams, thenGET /api/portal/teams/{id}/subscription-quotafor at most two teams.window_weighted_used / window_weighted_limit; Weekly =weekly_weighted_used / weekly_weighted_limit, resetweekly_resets_at. An idle window shows 0% with no invented reset time;window_resets_atis used only when present.oauth+web,dataConfidence: exact.Quota: Not included in this login response, no bars. 401/403 rejects the cached cookie.Privacy / safety decisions
SettingsStore.museCookieSource) and CLI (credentialSettings), following Zed's precedent. A pasted header with no explicit source means Manual. Existing installs make nodev.meta.airequest until the user opts in.[.chrome, .firefox], like LongCat's explicit order) to avoid Safari Full Disk Access and other Chromium Safe Storage prompts.auth; thedca:device token is sent only toapi.meta.ai, the cookie only todev.meta.ai(same split ashuggingface.ts).huggingface.tsdoes for its cookie profile.UI
Muse settings gain the shared
ProviderCookieSourceUI.picker(Automatic / Manual / Off, Off allowed), a secure Manual cookie field, and an "Open dev.meta.ai" action — the same wiring as T3 Chat. Existing localized strings are reused.Proof
.github/pr-proof/muse-web-quota-fallback.log— real account, production CLI path (codexbar usage --provider muse), 2026-09-26 03:22–03:39 AWST, idle 5-hour window:oauthNot included in this login response)oauth+weboauthWith an active window (
subs_usagepresent) both builds returned identicaloauthoutput (6% / 17%). The proof used a temporaryMUSE_AUTH_PATHfile and a Manual cookie in a temporaryCODEXBAR_CONFIG, so no CodexBar Keychain read occurred; both files were deleted afterwards. Token, cookie, email, and tier ID are redacted.Tests
Tests/CodexBarTests/MusePluginTests.swift, both plugin engines:dev.meta.airequest whensubs_usageis presentdev.meta.aibrowser session access stays off until configured(nil config, empty config, header-only → Manual, explicit Auto)Existing coverage searched
gh pr/issue list --searchformuse,meta.ai,dev.meta.ai,subscription-quota,llama_dev_sess,muse quota; clawsweeper triage labels on the Muse items.GETsubscription quota only.Commands run
swift test --filter 'MusePluginTests|MuseCredentialsTests|MuseKeychainAccessTests|ProviderArchitectureGatekeeperTests|ProviderPluginRuntimeTests|CookieProviderCutover|BrowserCookieAccessGate'(after rebase ontoa2cf7face)make check— 0 violationsCODEXBAR_TEST_SUITE_TIMEOUT=120 CODEXBAR_TEST_GROUP_SIZE=4 make test(pre-rebase): 360 groups; the only failure isUsageStoreCachedTokenHydrationTeststiming out at 120 s, which also times out on a cleanmainlocally because it loads the real Codex token cache../Scripts/regenerate-plugin-js.sh+tsc --project tsconfig.plugins.json