Findings

• No findings.

Summary

• Review mode: initial
• No issues found in the latest diff. Residual risk: I did not execute the test suite, and the new service tier behavior still depends on the installed Codex app-server accepting serviceTier for thread/start and turn/start at runtime.

Testing

• Not run (automation)

HAPI Bot

Findings

• [Major] Keepalive clears the persisted/default service tier on Codex startup — applyCurrentConfigToSession() runs when the Codex wrapper becomes ready, and setServiceTier(currentServiceTier ?? null) turns the untouched undefined state into explicit Standard. setCollaborationMode() then immediately pushes a keepalive, so the hub persists serviceTier: null before the user does anything. A resumed Fast session is silently downgraded, and account-default Fast is also disabled for new untouched sessions. Evidence cli/src/codex/runCodex.ts:109
  Suggested fix:

  const { api, session, sessionInfo } = bootstrap
  let currentServiceTier: string | null | undefined =
      sessionInfo.serviceTier === 'fast' ? 'fast' : undefined
  
  const applyCurrentConfigToSession = (options?: { syncModel?: boolean }) => {
      const sessionInstance = sessionWrapperRef.current
      if (!sessionInstance) return
      // Preserve the third state: undefined means "omit/leave account default".
      if (currentServiceTier !== undefined) {
          sessionInstance.setServiceTier(currentServiceTier)
      }
  }

Summary

• Review mode: follow-up after new commits
• Found one Major issue in the new service-tier plumbing: startup keepalive collapses “unset” into explicit Standard and overwrites Fast/default state.

Testing

• Not run (automation). Add a Codex resume/startup test that seeds serviceTier: 'fast' and asserts the first config sync/keepalive preserves fast, plus an untouched session test that asserts no service tier is emitted.

HAPI Bot

Findings

• [Major] Service tier persistence still collapses explicit Standard into “unset” — the follow-up keeps persisted Fast, but sessionInfo.serviceTier ?? undefined still maps stored null to undefined. Since the new /service-tier path stores explicit Standard as null, a user who turns Fast off loses that explicit Standard choice after restart/resume; later Codex starts/turns omit serviceTier instead of sending app-server null, so account/default Fast can come back. The nullable free-form schema also leaves unsupported tier strings accepted and forwarded. Evidence cli/src/codex/runCodex.ts:90, shared/src/apiTypes.ts:145, hub/src/web/routes/sessions.ts:579.
  Suggested fix:

  // shared: reserve null for untouched; persist explicit Standard distinctly.
  const ServiceTierRequestValueSchema = z.preprocess(
      (value) => value === null ? 'standard' : typeof value === 'string' ? value.trim().toLowerCase() : value,
      z.enum(['fast', 'standard'])
  )
  
  export const SessionServiceTierRequestSchema = z.object({
      serviceTier: ServiceTierRequestValueSchema
  })
  
  type StoredServiceTier = 'fast' | 'standard' | null
  type CodexServiceTier = 'fast' | null | undefined
  
  const toCodexServiceTier = (tier: StoredServiceTier | undefined): CodexServiceTier =>
      tier === 'standard' ? null : tier === 'fast' ? 'fast' : undefined

  Use the stored standard value when persisting/returning applied config, and translate to Codex app-server null only when building thread/start or turn/start params.

Summary

• Review mode: follow-up after new commits
• The prior Fast-resume regression is partially fixed, but the persisted representation still cannot distinguish untouched from explicit Standard. That makes Fast-off non-sticky after restart/resume and leaves invalid service-tier strings accepted.

Testing

• Not run (automation). Add regression coverage for: toggle Standard → persist distinct standard → restart → first Codex turn sends app-server serviceTier: null; and POST /service-tier rejects an unsupported value.

HAPI Bot

Findings

• [Major] Explicit Standard service tier is still persisted as “unset” — the UI sends null for Standard, the API schema accepts/forwards that same null, and Codex startup converts persisted null to undefined. That means a user who turns Fast off only sends app-server serviceTier: null while the process is alive; after restart/resume HAPI omits serviceTier, so an account/thread default Fast tier can come back. The same loose schema also accepts arbitrary non-empty strings and forwards them as tier ids. Evidence web/src/components/AssistantChat/HappyComposer.tsx:632, shared/src/apiTypes.ts:145, hub/src/web/routes/sessions.ts:579, cli/src/codex/runCodex.ts:90.
  Suggested fix:

  const ServiceTierRequestValueSchema = z.preprocess(
      (value) => value === null ? "standard" : typeof value === "string" ? value.trim().toLowerCase() : value,
      z.enum(["fast", "standard"])
  )
  
  type StoredServiceTier = "fast" | "standard" | null
  type CodexServiceTier = "fast" | null | undefined
  
  const toCodexServiceTier = (tier: StoredServiceTier | undefined): CodexServiceTier =>
      tier === "standard" ? null : tier === "fast" ? "fast" : undefined

  Store/return standard for an explicit Fast-off choice, reserve stored null for untouched, and translate standard to app-server null only when building thread/start / turn/start params.

Summary

• Review mode: follow-up after new commits
• The follow-up improves UI gating by reading the Codex model catalog, but the earlier Standard-vs-unset persistence issue remains unresolved. This still makes Fast-off non-sticky across restart/resume.

Testing

• Not run (automation). Add regression coverage for: Fast on -> Fast off -> persisted standard -> restart/resume -> first Codex turn includes app-server serviceTier: null; and POST /service-tier rejects unsupported strings.

HAPI Bot

Findings

• No issues found in the latest diff with confidence >= 80%.

Summary

• Review mode: follow-up after new commits
• The previous Standard-vs-untouched service tier issue appears resolved: the web/API path now sends standard, the hub rejects unsupported tier strings, persistence keeps the sentinel distinct from null, and the Codex app-server boundary translates standard to serviceTier: null only when building thread/turn params.
• Residual risk: I did not run the full suites in this automation pass, so this is a static review only.

Testing

• Not run (automation)

HAPI Bot

Findings

• No issues found in the latest diff with confidence >= 80%.

Summary

• Review mode: follow-up after new commits
• Re-reviewed the full PR diff, including the follow-up service-tier catalog/token changes and the Codex Fast mode path across web, hub persistence/RPC, shared schemas, CLI keepalive, slash commands, and Codex app-server request builders.
• Residual risk: this was a static review pass; I did not run the test suites.

Testing

• Not run (automation)

HAPI Bot

Findings

• [Major] Fast mode sends the wrong app-server tier value — the new catalog normalization says the Codex Fast tier's catalog id/request value is priority, but the request builder translates HAPI's stored fast state into serviceTier: 'fast'. That means /fast and the UI toggle can persist as Fast while thread/start / turn/start do not request the advertised app-server tier. Evidence cli/src/codex/utils/appServerConfig.ts:60.
  Suggested fix:

  function toAppServerServiceTier(stored: string | null | undefined): string | null | undefined {
      if (stored === 'fast') {
          return 'priority';
      }
      if (stored === 'standard') {
          return null;
      }
      return undefined;
  }

Summary

• Review mode: follow-up after new commits
• Re-reviewed the full PR diff and the follow-up resume propagation path. Found one app-server wire-value mismatch in the Fast-mode request translation.

Testing

• Not run (automation)

HAPI Bot

Findings

• [Minor] Validate CLI service-tier values before starting Codex — the web endpoint only accepts fast/standard, but the new --service-tier CLI path accepts any non-empty string. runCodex then seeds currentServiceTier from that option and the keepalive path can persist the invalid value, while app-server param building silently omits unknown tiers. Evidence cli/src/commands/codex.ts:80.
  Suggested fix:

  function parseServiceTier(value: string): 'fast' | 'standard' {
      const normalized = value.trim().toLowerCase()
      if (normalized === 'fast' || normalized === 'standard') {
          return normalized
      }
      throw new Error('Invalid --service-tier value')
  }
  
  // ...
  } else if (arg === '--service-tier') {
      const tier = commandArgs[++i]
      if (!tier) {
          throw new Error('Missing --service-tier value')
      }
      options.serviceTier = parseServiceTier(tier)
  }

Summary

• Review mode: follow-up after new commits
• Re-reviewed the full PR diff. The prior fast vs app-server priority finding appears addressed; one remaining ingress can still store unsupported service-tier values.

Testing

• Not run (automation; local runner does not have bun installed)

HAPI Bot

Findings

• No issues found.

Summary

• Review mode: follow-up after new commits
• Re-reviewed the full current PR diff. The previous CLI --service-tier validation finding is addressed in the latest head. Residual risk: I could not run local typecheck/tests in this environment.

Testing

• Not run (automation; bun is not installed in this runner)

HAPI Bot