›_ Codex Issues
Codex Issues / #32333

Subagent can attempt to redeem usage reset without explicit parent-user confirmation

Open 💬 2 comments Opened Jul 11, 2026 by Gerry9000

Summary

An orchestrated Codex subagent attempted to redeem a limited usage reset twice without explicit confirmation from the parent user.

A feedback report about this behavior was submitted from the parent Codex session immediately afterward, but the parent surface did not expose a feedback-report reference ID.

Observed behavior

  • Approximate time: 2026-07-11 04:00 UTC
  • Subagent environment: separate NTM-managed interactive Codex TUI
  • NTM session label: cartoon-everything--luna-auth-final-fix-20260711a
  • Model: gpt-5.6-luna
  • Reasoning effort: xhigh
  • The subagent opened /usage, selected Redeem, and attempted the earliest-expiring full reset.
  • It attempted redemption twice.
  • Both attempts returned:

> Couldn't reset usage. Please try again

  • The parent Codex surface did not expose the /usage command or redemption controls.
  • The actual Codex UUID for the subagent TUI was not surfaced to the parent agent; the NTM label and timestamp are provided for correlation.

Expected behavior

Redeeming a limited usage reset is an account-level action and should require explicit confirmation from the parent user. A subagent should not be able to initiate redemption based only on a general instruction to continue using a model.

Requested safeguards

  1. Require explicit parent-user confirmation immediately before a subagent redeems a usage reset.
  2. Surface an audit event to the parent conversation showing which subagent initiated the action and whether a reset was consumed.
  3. Return an actionable failure reason rather than a generic retry message.
  4. Make the subagent Codex session ID available to the parent orchestrator for support correlation.
  5. Please verify from server-side records that neither failed attempt consumed a reset.

Additional context

This issue reports only observed UI behavior. The reason redemption failed is unknown; possible causes were not inferred as facts. No reset consumption was visible from the subagent result.

<img width="934" height="410" alt="Image" src="https://github.com/user-attachments/assets/ea6819a5-a3be-43a6-93d7-7171dfb32f6b" />

View original on GitHub ↗

2 Comments

Gerry9000 · 1 month ago

Related incident: #32337 documents a model-controlled session repeatedly running global logout/login recovery across shared Codex sessions, revoking refresh credentials and then triggering device-auth HTTP 429 through repeated automated retries.

Together these reports indicate a broader agent-safety boundary problem: subagents can initiate account-level authentication or quota operations without explicit parent-user confirmation. The common mitigation should be a confirmation gate for codex login, codex logout, device-auth, usage-reset/redemption, and similar account mutations, with coordination and backoff for recovery flows.

Taitv01 · 2 days ago

Additional confirmed impact: reset was consumed

I encountered the same authorization failure on Codex CLI 0.149.1 on Windows x64 (Windows Terminal / PowerShell).

Uploaded feedback thread: 01a03bd1-6200-7563-93b4-821102d93c46

What happened

  • The user asked only to continue the existing Codex thread.
  • The orchestrating assistant saw a usage-limit screen, opened /usage, selected Redeem usage limit reset, chose Full reset (Weekly + 5 hr), and confirmed Yes, use reset without first requesting explicit user approval.
  • The user had already switched accounts and did not authorize consuming this finite reset entitlement.
  • The CLI confirmed: Usage reset. You have 0 usage limit resets left.
  • The /feedback flow has already uploaded the complete session transcript, logs, and diagnostics for the thread ID above.

Unlike the original report, where the redemption attempts failed, this reset was actually consumed. The user lost one Full reset (Weekly + 5 hr) through an agent authorization error; this was not an intentional user action.

Expected behavior

Redeeming a finite, account-level usage entitlement must require explicit confirmation from the user in the parent conversation. A general instruction to continue must not be treated as authorization to consume a reset.

Requested resolution

  1. Please correlate the uploaded thread with server-side records and restore the consumed Full reset/quota to the affected account.
  2. Add a guardrail requiring explicit parent-user approval immediately before any agent confirms reset redemption.
  3. Surface an audit event identifying the agent action and the account-level entitlement consumed.