apps/codex/src/monthly-report.ts (2)

76-79: Repeated type assertion suggests missing type definition.

The pattern (summary as MonthlyUsageSummary & { project?: string }) appears three times. Consider defining a proper type alias to avoid repetition and improve maintainability.

♻️ Suggested refactor

Define a local type near the function:

+type MonthlyUsageSummaryWithProject = MonthlyUsageSummary & { project?: string };

 const summaries = new Map<string, MonthlyUsageSummary>();
+// When groupByProject is true, summaries will have the project field populated

Then use the type consistently:

 if (groupByProject) {
-  (summary as MonthlyUsageSummary & { project?: string }).project =
+  (summary as MonthlyUsageSummaryWithProject).project =
     project ?? UNKNOWN_PROJECT_LABEL;
 }

Also applies to: 111-112, 138-138

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/monthly-report.ts` around lines 76 - 79, The repeated inline
cast (summary as MonthlyUsageSummary & { project?: string }) in
monthly-report.ts (seen around the summary assignments when groupByProject is
true) indicates a missing local type alias; create a single type alias (e.g.,
MonthlyUsageSummaryWithProject) near the top of the function or module that
extends MonthlyUsageSummary with an optional project?: string, then replace all
three occurrences of the inline intersection with that alias when assigning to
summary (used alongside groupByProject and UNKNOWN_PROJECT_LABEL) to remove
duplication and improve readability.

---

9-9: Import os is only used in test code.

The node:os import is only referenced within the import.meta.vitest test block (line 243). Consider moving this import inside the test block to clarify its scope and avoid loading the module in production.

♻️ Suggested refactor

-import os from 'node:os';

Then inside the test block:

import os from 'node:os';
const home = os.homedir();

Or use dynamic import within the test if preferred.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/monthly-report.ts` at line 9, Remove the top-level "import os
from 'node:os';" and instead import it only inside the test block that uses it
(the import.meta.vitest block around the tests near the bottom of
monthly-report.ts); either add "import os from 'node:os';" at the start of that
test block or perform a dynamic import there and call os.homedir() where the
test computes home — this ensures os is not loaded in production while keeping
the test reference local to import.meta.vitest.

apps/codex/src/commands/monthly.ts (1)

151-206: Table row rendering logic is duplicated between branches.

The row rendering code (lines 164-181 and 186-204) is nearly identical. The only difference is iterating over grouped projectRows vs flat rows. Consider extracting a helper function to reduce duplication.

♻️ Suggested refactor

Extract a helper function for rendering rows:

const renderRow = (row: MonthlyReportRow) => {
  const split = splitUsageTokens(row);
  totalsForDisplay.inputTokens += split.inputTokens;
  totalsForDisplay.outputTokens += split.outputTokens;
  totalsForDisplay.reasoningTokens += split.reasoningTokens;
  totalsForDisplay.cacheReadTokens += split.cacheReadTokens;
  totalsForDisplay.totalTokens += row.totalTokens;
  totalsForDisplay.costUSD += row.costUSD;
  table.push([
    row.month,
    formatModelsDisplayMultiline(formatModelsList(row.models)),
    formatNumber(split.inputTokens),
    formatNumber(split.outputTokens),
    formatNumber(split.reasoningTokens),
    formatNumber(split.cacheReadTokens),
    formatNumber(row.totalTokens),
    formatCurrency(row.costUSD),
  ]);
};

Then both branches become simpler.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/commands/monthly.ts` around lines 151 - 206, The row-rendering
logic is duplicated between the grouped-branches and the flat-rows branch;
extract a single helper (e.g., renderRow or renderRows) that accepts a
MonthlyReportRow (or an array) and performs the splitUsageTokens call, updates
totalsForDisplay (inputTokens, outputTokens, reasoningTokens, cacheReadTokens,
totalTokens, costUSD) and pushes the formatted row into table using
formatModelsDisplayMultiline(formatModelsList(...)), formatNumber(...), and
formatCurrency(...); then call this helper inside the grouped loop (for each
projectRows) and in the else branch (for each rows) so
groupRowsByProject/sortedProjects and the flat iteration reuse the same render
function.

apps/codex/src/commands/daily.ts (1)

151-206: Same table rendering duplication as monthly.ts.

Both daily.ts and monthly.ts have nearly identical table rendering logic with duplicated code between the project-grouped and ungrouped branches. Consider extracting this pattern to a shared utility in command-utils.ts.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/commands/daily.ts` around lines 151 - 206, The table rendering
in daily.ts duplicates the same project-grouped vs ungrouped logic found in
monthly.ts; extract a shared function (e.g., renderUsageTable) into
command-utils.ts that accepts parameters like rows, table, totalsForDisplay,
useInstances, and TABLE_COLUMN_COUNT and encapsulates the grouping
(groupRowsByProject), per-row token splitting (splitUsageTokens), totals
accumulation (totalsForDisplay.*), row formatting (formatModelsDisplayMultiline,
formatModelsList, formatNumber, formatCurrency) and separators
(addEmptySeparatorRow); then replace the duplicated blocks in daily.ts (and
monthly.ts) to call renderUsageTable(...) to avoid repetition and keep the same
behavior and symbols.

apps/codex/src/session-report.ts (2)

9-9: Import os is only used in test code.

Same as monthly-report.ts, the node:os import is only used within the test block. Consider moving it inside the test scope.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/session-report.ts` at line 9, The top-level import "import os
from 'node:os'" is only used in test code; move the import into the test scope
to avoid importing node:os in production. Locate the "os" import in
apps/codex/src/session-report.ts and remove the top-level import, then add a
local import inside the test block (e.g., within the describe/it or conditional
that references os) so only tests require the module.

---

166-172: Complex nested ternary reduces readability.

This ternary chain is difficult to parse at a glance. Consider extracting to a helper function for clarity.

♻️ Suggested refactor

+function resolveProjectLabel(
+  groupByProject: boolean,
+  summaryProject: string | undefined,
+  projectKeys: Set<string>,
+): string | undefined {
+  if (groupByProject) {
+    return summaryProject;
+  }
+  if (projectKeys.size !== 1) {
+    return MIXED_PROJECT_LABEL;
+  }
+  const singleKey = Array.from(projectKeys)[0];
+  return singleKey === UNKNOWN_PROJECT_LABEL ? undefined : singleKey;
+}

 rows.push({
   sessionId: summary.sessionId,
-  project: groupByProject
-    ? summary.project
-    : summary.projectKeys.size === 1
-      ? Array.from(summary.projectKeys)[0] === UNKNOWN_PROJECT_LABEL
-        ? undefined
-        : Array.from(summary.projectKeys)[0]
-      : MIXED_PROJECT_LABEL,
+  project: resolveProjectLabel(groupByProject, summary.project, summary.projectKeys),
   lastActivity: summary.lastTimestamp,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/session-report.ts` around lines 166 - 172, The nested ternary
that computes the project field is hard to read; extract its logic into a small
helper (e.g., getProjectValue or determineProjectLabel) that accepts summary and
groupByProject and returns either summary.project, undefined, a single project
key, or MIXED_PROJECT_LABEL based on the current checks (use
summary.projectKeys, UNKNOWN_PROJECT_LABEL, and groupByProject). Replace the
inline ternary in the project property with a call to this helper so the
conditional logic is isolated and clearer.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

apps/codex/src/data-loader.ts (1)

221-224: ⚠️ Potential issue | 🟠 Major

Only suppress auto-archived warnings for missing-directory (ENOENT) cases

Line 221 currently suppresses all failures for the optional archived directory, including permission/configuration failures. That can hide real filesystem problems.

Suggested fix

 		if (Result.isFailure(statResult)) {
-			if (!optionalDirs.has(directoryPath)) {
+			const errorCode =
+				typeof statResult.error === "object" &&
+				statResult.error != null &&
+				"code" in statResult.error
+					? (statResult.error as NodeJS.ErrnoException).code
+					: undefined;
+			const isOptionalMissing = optionalDirs.has(directoryPath) && errorCode === "ENOENT";
+			if (!isOptionalMissing) {
 				missingDirectories.push(directoryPath);
 			}
 			continue;
 		}
 
 		if (!statResult.value.isDirectory()) {
 			if (!optionalDirs.has(directoryPath)) {
 				missingDirectories.push(directoryPath);
 			}
 			continue;
 		}

Also applies to: 229-231

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/codex/src/data-loader.ts` around lines 221 - 224, The current check
treating any Result.isFailure(statResult) for optionalDirs as non-fatal hides
real FS errors; update the logic around the statResult handling (the block that
references statResult, optionalDirs, and missingDirectories) to only suppress
the error when the underlying error code equals 'ENOENT' (or its platform
equivalent) — for other failures, either rethrow or surface/log the error
instead of pushing directoryPath to missingDirectories; apply the same change to
the similar block that covers lines 229-231 so both statResult checks only
swallow ENOENT and not permission/configuration errors.