Repository navigation
Subagent can attempt to redeem usage reset without explicit parent-user confirmation #32333
Description
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
/usagecommand 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
- Require explicit parent-user confirmation immediately before a subagent redeems a usage reset.
- Surface an audit event to the parent conversation showing which subagent initiated the action and whether a reset was consumed.
- Return an actionable failure reason rather than a generic retry message.
- Make the subagent Codex session ID available to the parent orchestrator for support correlation.
- 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.
Activity
Gerry9000 commentedon Jul 11, 2026
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 commentedon Aug 26, 2026
Additional confirmed impact: reset was consumed
I encountered the same authorization failure on Codex CLI
0.149.1on Windows x64 (Windows Terminal / PowerShell).Uploaded feedback thread:
01a03bd1-6200-7563-93b4-821102d93c46What happened
/usage, selected Redeem usage limit reset, chose Full reset (Weekly + 5 hr), and confirmed Yes, use reset without first requesting explicit user approval.Usage reset. You have 0 usage limit resets left./feedbackflow 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
continuemust not be treated as authorization to consume a reset.Requested resolution
joonyeonglim commentedon Aug 31, 2026
Additional confirmed reproduction: an orchestrating Codex agent redeemed a reset through raw PTY input without owner approval
This is a confirmed instance of the authorization-boundary problem described in this issue. Unlike the earlier failed attempts, the reset was actually consumed.
Environment
0.151.0gpt-5.6-lunaDarwin 25.6.0 arm641.4.192integrated terminal/PTyskipCodexRateLimitResetConfirm=falseWhat happened
The parent goal asked the agent to continue an R08 verification after a rate-limited session ended. It did not authorize spending a banked reset. The orchestrating Codex agent nevertheless decided that the available reset was a resource it could use and drove the live Codex TUI:
2026-08-30T15:54:56Z, the TUI showedUsage limit resetswith1. Full resetand2. Cancel.15:55:03Z, the agent sent a blank Enter, selectingFull reset.15:55:08Z, the TUI showedUse this reset?with1. Yes, use resetand2. No, go back(cursor onNo).15:55:16Z, the agent sent an up-arrow followed by Enter. The selection moved toYes, use resetand was confirmed.15:55:16Z, the local Codex log recordedaccount/rateLimitResetCredit/consumefromcodex-tui0.151.0.Normal
orca terminal sendprompt delivery was rejected withagent_prompt_blocked; the agent then used the--interruptpath to send raw PTY bytes. Those inputs were accepted by the TUI. The external orchestrator was only the transport: the Codex TUI accepted indistinguishable agent-originated keystrokes for a destructive account action.Impact
4%immediately before the action.0%immediately afterward and the weekly reset window was re-anchored roughly seven days later.Expected behavior
The confirmation dialog alone is not an owner-authorization boundary. A subagent or orchestrator should not be able to redeem a finite account reset by sending
/usage, numeric choices, arrow keys, or Enter to a TUI, even when the confirmation preference is enabled.Please consider:
account/rateLimitResetCredit/consume.--interrupt, or otherwise distinguishing human input from automation.No access tokens, account IDs, email addresses, or private repository data are included here. Redacted local logs can be provided if needed.