[only21mil]

Problem

CLIProxyAPI serves its management API under /v0/management. That base URL is the obvious thing to paste next to a management key. A hub saved that way (https://hub.example.com/v0/management, with or without a trailing / or a path prefix) gets no accounts in Usage → Limits. Every management call goes to /v0/management/v0/management/..., the hub answers 404, and the only message is "The hub answered with HTTP 404." The account list, usage, credits and Use reset calls all fail the same way.

The Add hub dialog saves the URL as typed, so the server is the one place that sees every saved form, including older hubs and hand-edited settings.json.

Change

CliproxyApi.management already strips a trailing /management.html (#25579) before resolving v0/management/<path> relative to the hub URL (#19336). This adds /v0/management to that same trailing-suffix strip. Prefix hubs keep their prefix (/cliproxy/v0/management → /cliproxy/), and a path such as /team-management.html is still left alone.

The existing "keeps the path of a hub served under a prefix" table gets the /cliproxy/v0/management and /cliproxy/v0/management/ rows. Its startsWith("/cliproxy/v0/management/") check also matched the doubled path, so the table now also checks that the first request is exactly /cliproxy/v0/management/auth-files.

Scope and approval

This is a small, focused fix for an obvious bug. It qualifies for the no-prior-issue exception: one regex alternative in the URL normalization that #25579 added, plus two test rows. No client, contract or settings change. #28835 reported the related management.html form, which #25579 fixed. Nothing on main covers the /v0/management form.

Verification

vp test run src/usage/cliproxyApi.test.ts from apps/server:

• Before the fix (new rows on the old code): Tests 2 failed | 26 passed (28). Both failures are the new rows: expected /cliproxy/v0/management/auth-files, received /cliproxy/v0/management/v0/management/auth-files.
• With the fix: Tests 28 passed (28).

vp run check:changed a9e709f15 passed: format, lint, knip, typecheck and tests.

Real hub on desktop, iOS and Android. I ran main (1c65ad032e), then this head (1e4debc22b), then this head merged locally with main (3605a3edf2). For each, I started the Linux desktop app (vp run dev:desktop, Electron under Xvfb) in a fresh test home and added a running CLIProxyAPI hub in Settings → Providers → Add hub by its /v0/management URL and a valid management key. Desktop input was sent through the debugging port. In a second desktop run per revision, I paired an iOS 26.5 simulator and an Android 16 emulator (software rendering, SwiftShader) to its server and tapped through the T3 Device panel. Both ran main's app, as the change is server-only. The runs only read from the hub.

On main, all three show only "Test hub: The hub answered with HTTP 404."

On this head, all three list the hub's accounts with no hub error. Account labels are initials only.

The head merged with main (3605a3edf2) shows the same list on all three surfaces; captures kept in my record.

The earlier web run against a real hub, and the stand-in hub (stub) run for the request log

Real hub. I ran vp run dev on main (4c36119) and on this head (1e4debc22b), each in a fresh test home, against a running CLIProxyAPI hub with a valid management key, saved with its /v0/management URL, and opened Usage → Limits. How that page was driven was not recorded. The run only read from the hub.

Before, on main: no accounts, only "Test hub: The hub answered with HTTP 404."

After, on this head: Usage → Limits lists the hub's Claude and Codex accounts with their weekly and session windows. The account count matches the hub's own auth-files list. Avatars show initials only.

The "Codex could not read usage (JSON-RPC -32600)" line in these web captures comes from the test machine's local Codex CLI, which has no login there. It is unrelated to the hub.

maria-rcks's run drove the web client with Playwright through the debugging port against CLIProxyAPI 8.0.48: /v0/management/v0/management/auth-files on main (4c36119), /v0/management/auth-files on this head (1e4debc22b).

Stand-in hub (stub), for the request log. Same steps on main (a9e709f15) and this head (1e4debc22b) in the T3 Browser panel, with a local stand-in hub on 127.0.0.1 that answers only /v0/management/* and returns two fake Codex accounts. The hub was added in Settings → Providers → Add hub with this URL and a fake key:

Before, on main: only the 404 for the hub. The stand-in hub logged GET /v0/management/v0/management/auth-files.

After, on this head: the same saved hub shows its two fake accounts, and the card names the hub as its source. The stand-in hub logged GET /v0/management/auth-files and POST /v0/management/api-call.

Not checked: the macOS and Windows desktop apps.

Prior PRs

• fix(usage): a CLIProxy hub saved as its management.html panel URL shows accounts again #25579 (@Jolymmiles) added the trailing-suffix strip this extends.
• fix(usage): a CLIProxyAPI hub served under a path keeps its path #19336 (@Pipyakas) made hub paths resolve relative to the hub URL.
• fix(server): CLIProxyAPI hubs saved with their panel URL reach the management API #30234 (@sidhartha1s) changed the same lines for the management.html form only and was closed without merging.

Generated with Claude Opus 5.5 in T3 Code Nightly

[macroscopeapp]

Approvability

Verdict: Approved at 1e4debc

Macroscope's review found this PR approvable — This fixes hub account and usage access when the saved URL ends in /v0/management. Requests retain the same origin, credentials and existing action safeguards; no product defaults change.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

CliproxyApi.management now strips an optional trailing /v0/management suffix before appending the API path. The path-prefix test covers URLs ending in /v0/management and /v0/management/ and checks the resulting request path.

Changes: Management URL normalization

Layer / File(s)	Summary
Normalize management URLs and verify requests apps/server/src/usage/cliproxyApi.ts, apps/server/src/usage/cliproxyApi.test.ts	The management URL handling strips an optional trailing /v0/management suffix. The test checks that the first request targets /cliproxy/v0/management/auth-files for hub URLs with and without a trailing slash.

Estimated code review effort: 2 (Simple) | ~5 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#25579: This PR also changes suffix normalization in CliproxyApi.management and overlaps with this change.
• pingdotgg/t3code#30234: This PR changes suffix normalization in the same function and adds path-prefix test cases.

Suggested labels: bugfix

Suggested reviewers: jolymmiles

Merge Risk: Minimal · up to 1e4de

Hub URLs with the management suffix are normalized while unrelated paths remain intact. No merge-blocking risk was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: a CLIProxyAPI hub saved with its /v0/management API URL now works and shows accounts. It fits the code change, which adds /v0/management to the trailing suffixes strip…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections, and each is filled in. The Problem section names the failing hub URL form, the 4…

Full details: Title check

Explanation

The title names the main change: a CLIProxyAPI hub saved with its /v0/management API URL now works and shows accounts. It fits the code change, which adds /v0/management to the trailing suffixes stripped by CliproxyApi.management, and the test changes that cover it. The title follows the conventional commit form and is specific enough for a teammate scanning history.

Full details: Description check

Explanation

The description follows the repository template. It has Problem, Change, Scope and approval, and Verification sections, and each is filled in. The Problem section names the failing hub URL form, the 404 symptom, and the affected calls. The Change section explains the one-line regex extension and its prefix handling. The Scope section explains why no prior issue is needed and cites related PRs. The Verification section gives the exact test command, before and after results, the full check run, and desktop, iOS, Android, and web evidence with captures. It also states what was not checked (macOS and Windows desktop). The template's agent-model line is present at the end. Minor gaps: the verification images are hosted on external gists, and the description is long, but the required information is present and specific.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: a9e709f
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 0ea20fec-c2f5-4cca-b3d4-31f1c461b34b

Commits

Reviewing files that changed from the base of the PR and between a9e709f and 1e4debc.

Files selected for processing: 2

• apps/server/src/usage/cliproxyApi.test.ts
• apps/server/src/usage/cliproxyApi.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 2 remain after this review.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

partial verification on linux with real CLIProxyAPI 8.0.48, no mocks or demo data. tested github/main at 4c361199f47f6ea32a2c14835df392640d0f7c63, then the exact pr head 1e4debc22b3dadca4058e44d2b1e1fd0bb5738ac, with one dev server at a time. drove the web client with repo playwright and /usr/bin/google-chrome.

added the hub through settings → providers with http://127.0.0.1:28317/v0/management, then opened usage → limits and refreshed. reused the same saved settings across both revisions. loopback capture confirmed the actual outbound requests:

main: GET /v0/management/v0/management/auth-files HTTP/1.1
pr:   GET /v0/management/auth-files HTTP/1.1

the doubled request path is reproduced on main and corrected on the pr through the running client/server path. this does not prove successful account loading, for the credential reason below.

created a project pointing at the real main git worktree through the app and completed real codex gpt-6.1-sol turns on both revisions. the recording shows the pr turn completing. also removed the hub through settings and confirmed its error disappeared from limits while the separate local codex usage error remained.

cliproxyApi.test.ts: 28/28 passed through blacksmith-check. existing head CI: 31 successful, zero failing or pending. no code changes.

runtime transcript

Not verified

successful account loading, account usage, credits and reset consumption remain blocked. the VM provides a provider API key, which the real proxy rejects as a management key (401, then 403 on subsequent requests). management authentication masks the original 404 symptom on this proxy, so only the doubled path was reproduced. stopped management requests rather than substituting fake accounts or claiming success. a valid management credential is needed to complete this verification.

local codex usage also reports JSON-RPC -32600 on both revisions, although real provider turns work. native desktop, iOS/Android, other providers, path-prefix deployments and remote/tunnel connections were not exercised. the existing tests cover the URL variants, but are not real deployment evidence.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

Thanks @maria-rcks. Your run on a real CLIProxyAPI 8.0.48 release covers a gap the PR body left open: until now the doubled path was shown only against a stand-in hub. Your request capture shows main sending /v0/management/v0/management/auth-files and this head sending /v0/management/auth-files from the same saved hub, end to end through the running client and server. Your remove-hub check also shows the hub's error clearing from Limits on its own.

You're right that account loading on a real release is still unproven. Without a management key the proxy answers 401/403 before it ever gets to the path. Nobody needs to share a key to close that gap.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

Follow-up on the part that was still open: accounts actually loading.

We ran vp run dev on head 1e4debc and on current main (4c36119), each in a fresh test home, against our own running CLIProxyAPI hub with a valid management key. Both had the hub saved with its /v0/management URL. Nothing on the hub was changed; the test only read from it.

• Head: Usage → Limits lists the hub's Claude and Codex accounts with their weekly and session windows. The counts match the hub's own auth-files list.
• main: no accounts, only "Test hub: The hub answered with HTTP 404."

Account avatars show only initials. The Codex -32600 line comes from the test machine's local Codex CLI, as in the PR body.

Before (main):

After (head):

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

Closing this: it is not a bug fix, and this repository now takes only bug fixes from outside contributors. The branch stays on my fork if it is useful.