codex:resume / codex-rescue burned 27% of weekly limit (71%→98%) over ~12h with zero forward progress

Summary

Invoked /codex:review (which forwards to the codex:codex-rescue subagent → codex-companion.mjs task ... --resume-last) on a finished plan. The run spun for ~12 hours and consumed roughly 27 percentage points of my weekly Claude Code usage (71% → 98%), without taking a single forward step on the work. When I returned, the orchestrator was still showing Codex review… (27s · ↓ 85.4k tokens · still thinking) — i.e. the review never produced a verdict, never wrote a finding, never edited a file. The plan it was reviewing was not modified between when codex started and when I killed it.

The screenshot attached shows the state I returned to. Note the bottom status bar: 5h:88% 7d:96% — i.e. weekly cap is on the verge of exhausting purely from this stalled codex:rescue invocation continuing to call out.

Repro context

• Plugin: codex@openai-codex v1.0.3 (the OpenAI-published Codex companion plugin)
• Subagent: codex:codex-rescue (defined in plugins/codex/agents/codex-rescue.md)
• Command path: /codex:review → forwards to node \"\${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs\" task ... --resume-last
• Trigger: explicit /codex:review invocation against a finished planning doc (5 markdown files, ~80 KB total)
• Claude Code: Opus 4.7 (1M context), v2.1.119
• OS: macOS Darwin 25.4.0

What I'd expect

A review subagent that delegates to an external runtime should either:

1. Stream incremental findings to the parent so the loop can be detected, OR
2. Hard-cap on wall-clock / token spend / no-progress watchdog, OR
3. Surface a clear failure when the underlying Codex CLI hangs

What actually happens: the --resume-last mode appears to keep the polling loop alive indefinitely against a Codex session that's stuck in \"still thinking\". The wrapper has no upper bound, so it silently incinerates Claude Code quota while doing nothing.

Asks

• Default --resume-last to off for /codex:review (treat it as fresh per invocation).
• Add a watchdog: if Codex emits no finding within N minutes, kill the wrapper and surface an error to the orchestrator.
• Surface running token / wall-clock cost into the parent transcript so the user can intervene before the weekly cap blows.
• Document the failure mode in the codex plugin README — there's currently no warning that a stuck Codex session can drain Claude Code quota for hours.

Mitigation I've taken locally

Disabled the codex plugin manifest (mv plugin.json plugin.json.disabled-2026-04-28) so it no longer loads. Will not re-enable until this is addressed.

Screenshot

Attaching screenshot via web UI after issue creation (gh CLI does not support binary gist upload). Shows the orchestrator stuck on Codex review… (27s · still thinking) with weekly usage at 7d:96%.