[Bug]: Usage page misses Codex usage from provider instances with a custom CODEX_HOME #5805

Activity

1. zenDevNomad

   changed the title [-]Usage page shows no Codex usage when Codex is configured through provider instances[/-] [+][Bug]: Usage page shows no Codex usage when Codex is configured through provider instances[/+] on Aug 9, 2026
2. zenDevNomad

   changed the title [-][Bug]: Usage page shows no Codex usage when Codex is configured through provider instances[/-] [+][Bug]: Usage page misses Codex usage from provider instances with a custom CODEX_HOME[/+] on Aug 9, 2026
3. zucram commented on Aug 9, 2026

   

   zucram

   on Aug 9, 2026 – with ChatGPT Codex Connector

   More actions

   I reproduced a stronger variant of this on Linux with t3@0.0.33-nightly.20260809.1042: the Usage page settles at $0.00 / 0 processed tokens for every provider, even though both Codex and Claude have substantial recent transcript history.

   Environment that exposes it

   The T3 server is intentionally launched with separate workspace and provider homes:

   Environment=HOME=/srv/projects
   Environment=CODEX_HOME=/root/.codex
   ExecStart=t3 serve --base-dir /root/.local/share/t3code /srv/projects

   This is useful for a remote server: HOME=/srv/projects makes the project picker open at the workspace root, while CODEX_HOME=/root/.codex keeps the Codex state/auth location explicit.

   The persisted settings have no legacy providers object. Claude is configured through providerInstances with a custom config.homePath. Codex uses the process-level CODEX_HOME.

   Observed resolution

   The shipped UsageService.resolveTranscriptDirs reads:

   settings.providers.claudeAgent
   settings.providers.codex

   It does not enumerate settings.providerInstances.

   For Codex, the empty legacy config reaches resolveCodexHomeLayout, whose default is based on NodeOS.homedir(). In this process:

   os.homedir() = /srv/projects
   CODEX_HOME   = /root/.codex
   

   The usage scan consequently resolves these nonexistent roots:

   /srv/projects/.codex/sessions
   /srv/projects/.claude/projects
   /srv/projects/projects
   

   The real roots are:

   /root/.codex/sessions
   <configured Claude provider instance home>/projects
   

   So this is not limited to an explicitly configured custom Codex instance: setting CODEX_HOME independently of HOME is enough to lose all Codex usage. Reading only the legacy provider blob also loses Claude usage configured by the current providerInstances model.

   Evidence that the transcripts are valid

   For the same 30-day window shown in the UI, a read-only reproduction of the parsing rules shipped in .1042 found:

   Provider	Transcript files with in-window records	Parsed records	Parser-compatible tokens
   Codex	83	12,311	1,477,313,596
   Claude	31	2,802	421,490,501

   These figures are only intended to prove that compatible, nonzero records exist; they are not asserted as billing totals (and Codex fork accounting is separately covered by #5758).

   The live server.getUsageSummary calls complete successfully. There is no server-side read failure: the service returns an empty summary because both resolved roots are missing. That explains why the settled UI confidently renders zeros instead of an error. A transient reconnect can separately flash the generic “environment could not report usage” message, but it is not the cause of the persistent zero result.

   Expected behavior

   Usage collection should use the same effective provider-home resolution as provider execution:

   1. Enumerate enabled providerInstances for Claude and Codex, rather than reading only settings.providers.<kind>.
   2. For an implicit/default Codex configuration with a blank homePath, honor CODEX_HOME before falling back to homedir()/.codex.
   3. Scan distinct physical transcript roots once if multiple instances share a home or a Codex auth overlay.
   4. Preserve per-source status so a missing configured root is visible rather than silently appearing as genuine zero usage.

   Suggested regression coverage

   • HOME !== CODEX_HOME, with no explicit providerInstances.codex entry.
   • Claude configured only through providerInstances.<id>.config.homePath.
   • Multiple instances with different transcript homes.
   • Multiple instances resolving to the same shared transcript directory (no double count).
   • Both resolved roots missing: response sources identify them as missing and the UI does not present the result as a trustworthy zero.

   This reproduction confirms the cause described in the issue and shows that it affects the standard process-level CODEX_HOME path as well as custom instance homes.
4. bwmp commented on Aug 24, 2026

   

   bwmp

   on Aug 24, 2026

   More actions

   Reproduced with T3 Code 0.0.34-nightly.20260824.1173 on Windows 11 x64 using the desktop app. The incorrect result is identical on desktop, web, and mobile.

   Two enabled claudeAgent provider instances use separate CLAUDE_CONFIG_DIR paths: ~/.claude-work and ~/.claude-personal. Their projects directories contain 28 and 166 .jsonl transcripts respectively, but neither appears in Usage.

   server.getUsageSummary and UsageService.resolveTranscriptDirs complete successfully; this is not a scan error. In the installed source, UsageService.resolveTranscriptDirs still resolves Claude exclusively from settings.providers.claudeAgent, ignoring both enabled entries in settings.providerInstances.

   Current main has the same implementation, so the issue does not appear fixed in a newer build.

   Confirmed by Codex (GPT-5) via t3 triage.
5. juliusmarminge commented on Sep 13, 2026

   

   juliusmarminge

   on Sep 13, 2026

   Member

   More actions

   Closing as fixed by #11485 — usage now follows each configured Codex/Claude/Grok account home (including custom CODEX_HOME / CLAUDE_CONFIG_DIR).
6. juliusmarminge

   closed this as completedon Sep 13, 2026