You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Missing UI for switching codexAccountMode (Pool/Direct) on Providers page #586
changed the title [-][버그] Providers 페이지에서 codexAccountMode (Pool/Direct) 전환 UI 누락[/-][+][Bug] Missing UI for switching codexAccountMode (Pool/Direct) on Providers page[/+]on Jul 28, 2026
Triage: backend exists, the gap is entirely in the dashboard
Confirmed on dev (7710185c0). Your reading is right on both halves.
The management route is implemented: src/server/management/provider-routes.ts:137-167 handles PATCH /api/providers?name=openai with codexAccountMode, validates it as pool or direct (:148), restricts it to the openai provider (:145), refuses to combine it with other patch fields (:143), and runs the dedicated side-effect path (quota cache clear, thread map) before writing config.providers.openai at :155.
No dashboard code calls it. gui/src/pages/CodexAuth.tsx reads the mode for its banner only, and the Providers > Settings tab has no control bound to that field — which is why the JSON editor is the only route today, and why the README line ("Change the mode on the dashboard's Providers page") currently overstates what the UI offers.
Where this needs a decision rather than a patch: the mode is not an ordinary provider setting. Switching it clears quota state and remaps threads, and the surface that already displays the mode is Codex Auth, not Providers. So there is a real choice between adding a control to Providers > Settings (matching the README), promoting the existing Codex Auth banner into the control (matching where users already see the state), or doing both with one canonical location. That is an information-architecture call for the maintainers, so we are not implementing it unilaterally.
Whichever way it lands, the README wording and the UI should end up agreeing — right now they do not, and that mismatch is the part of this report that is unambiguous.
Triage: confirmed — the backend can switch codexAccountMode, but the Providers GUI only renders the mode as badges; no frontend control calls the PATCH. Still open as a GUI feature gap.
The backend is complete — src/server/management/provider-routes.ts:151-180 has a dedicated PATCH for codexAccountMode. Nothing in the GUI calls it. The Providers page renders the mode as a badge only (gui/src/components/provider-catalog/ProviderCatalog.tsx:84-85), and the Codex Auth page shows a read-only banner (gui/src/pages/CodexAuth.tsx:22-50). So the API you would need already exists and the control does not, which is exactly the gap you described.
The work is small but not trivial, and the non-obvious part is picking one canonical surface. Both pages currently display the mode, so adding a switch to both would create two places that can disagree during a refresh. Switching pool↔direct also changes thread affinity and quota accounting, so the control needs a confirmation step and a state refresh rather than a bare toggle.
Left open with that shape recorded. Not forgotten.
Fixed by #935 (merged into \dev\ as 010c7f0). The Providers > OpenAI (Codex login) Settings tab now has a Pool/Direct account mode selector that calls the dedicated mode PATCH, with a confirmation step, quota/account-state refresh, and tests. It will reach users with the next release promoted from \dev.
Activity
[-][버그] Providers 페이지에서 codexAccountMode (Pool/Direct) 전환 UI 누락[/-][+][Bug] Missing UI for switching codexAccountMode (Pool/Direct) on Providers page[/+]github-actions commentedon Jul 28, 2026
Automated translation bookkeeping — detected language: unknown.
lidge-jun commentedon Jul 28, 2026
Triage: backend exists, the gap is entirely in the dashboard
Confirmed on
dev(7710185c0). Your reading is right on both halves.The management route is implemented:
src/server/management/provider-routes.ts:137-167handlesPATCH /api/providers?name=openaiwithcodexAccountMode, validates it aspoolordirect(:148), restricts it to theopenaiprovider (:145), refuses to combine it with other patch fields (:143), and runs the dedicated side-effect path (quota cache clear, thread map) before writingconfig.providers.openaiat:155.No dashboard code calls it.
gui/src/pages/CodexAuth.tsxreads the mode for its banner only, and the Providers > Settings tab has no control bound to that field — which is why the JSON editor is the only route today, and why the README line ("Change the mode on the dashboard's Providers page") currently overstates what the UI offers.Where this needs a decision rather than a patch: the mode is not an ordinary provider setting. Switching it clears quota state and remaps threads, and the surface that already displays the mode is Codex Auth, not Providers. So there is a real choice between adding a control to Providers > Settings (matching the README), promoting the existing Codex Auth banner into the control (matching where users already see the state), or doing both with one canonical location. That is an information-architecture call for the maintainers, so we are not implementing it unilaterally.
Whichever way it lands, the README wording and the UI should end up agreeing — right now they do not, and that mismatch is the part of this report that is unambiguous.
lidge-jun commentedon Aug 2, 2026
Triage: confirmed — the backend can switch codexAccountMode, but the Providers GUI only renders the mode as badges; no frontend control calls the PATCH. Still open as a GUI feature gap.
lidge-jun commentedon Aug 3, 2026
Confirmed still real on current
dev.The backend is complete —
src/server/management/provider-routes.ts:151-180has a dedicated PATCH forcodexAccountMode. Nothing in the GUI calls it. The Providers page renders the mode as a badge only (gui/src/components/provider-catalog/ProviderCatalog.tsx:84-85), and the Codex Auth page shows a read-only banner (gui/src/pages/CodexAuth.tsx:22-50). So the API you would need already exists and the control does not, which is exactly the gap you described.The work is small but not trivial, and the non-obvious part is picking one canonical surface. Both pages currently display the mode, so adding a switch to both would create two places that can disagree during a refresh. Switching pool↔direct also changes thread affinity and quota accounting, so the control needs a confirmation step and a state refresh rather than a bare toggle.
Left open with that shape recorded. Not forgotten.
Wibias commentedon Aug 3, 2026
[GD] Opened PR #935 to address this.
Wibias commentedon Aug 3, 2026
Fixed by #935 (merged into \dev\ as 010c7f0). The Providers > OpenAI (Codex login) Settings tab now has a Pool/Direct account mode selector that calls the dedicated mode PATCH, with a confirmation step, quota/account-state refresh, and tests. It will reach users with the next release promoted from \dev.