Repository navigation
Description
Summary
Calling Skill(codex:rescue) programmatically from the main Claude Code
agent (not via the user-typed /codex:rescue slash command) triggers an
infinite recursion that hangs the session until manual cancellation. The
Codex CLI is never invoked.
Confirmed on plugin versions 1.0.2 and 1.0.3.
Repro
From the main agent (not the user's slash-command path):
Skill(codex:rescue, args: "<any rescue task>")
Observed behavior
- UI appears frozen; no Codex job is created.
- No entry under
~/.claude/plugins/data/codex-openai-codex/state/<project>/state.json. - No log file under
~/.claude/plugins/data/codex-openai-codex/state/<project>/jobs/. - After ~3+ minutes, user must cancel manually.
Root cause (from subagent fork log)
Timeline from ~/.claude/projects/<project>/<session>/subagents/agent-*.jsonl
(agentType: "general-purpose"):
T+0s fork subagent starts, loads rescue.md instructions + raw user request
T+2s "I'll check for a resumable rescue thread first"
T+3s Bash: codex-companion.mjs task-resume-candidate -> available: false ✓
T+15s ❌ Skill(codex:codex-rescue) attempted -> "Unknown skill: codex:codex-rescue"
T+20s ❌ recovery attempt: Skill(codex:rescue) called again (recurses into self)
T+217s hang; user cancels
Why:
commands/rescue.mdfrontmatter setscontext: fork, so invocation
forks ageneral-purposesubagent and loadsrescue.mdbody as its
instructions.- The body instructs: "Route this request to the
codex:codex-rescue
subagent." codex:codex-rescueis an agent (Agenttool'ssubagent_type),
not a skill (Skilltool).- The forked general-purpose agent resolves the ambiguous wording by
tryingSkill(codex:codex-rescue)→Unknown skillerror. - As a fallback, it re-invokes
Skill(codex:rescue)— which forks
itself again → infinite recursion → hang.
Why the slash command works but programmatic call doesn't
When the user types /codex:rescue, Claude Code's slash-command router
handles dispatch and does not fall into the "route to subagent" prose
resolution path. When the main agent calls Skill(codex:rescue), the
fork sees only the rescue.md body and has to interpret it — hence the
ambiguity.
Suggested fix
Change commands/rescue.md to name the transport explicitly, instead of
"route to subagent" prose. For example:
- Replace "Route this request to the
codex:codex-rescuesubagent" with
an explicit instruction to use theAgenttool with
subagent_type: codex:codex-rescue, or - Restrict
allowed-toolsin rescue.md frontmatter toAgentonly
(excludeSkill), which makes the recursive path impossible.
Workaround
Main agent calls the subagent directly:
Agent(subagent_type="codex:codex-rescue", prompt="...")
This skips the fork/resume-candidate check and invokes
node codex-companion.mjs task ... immediately. Users may see a
one-time permission prompt if Agent(codex:codex-rescue) is not in
their settings allow list.
Environment
- Claude Code on macOS (Darwin 25.2.0)
- Plugin versions tested: 1.0.2, 1.0.3
- Model: Claude Opus 4.6
Activity
rsktash commentedon Apr 16, 2026
it's burning claude tokens. pls, fix it
pengyou200902 commentedon Apr 16, 2026
+1 here, also seeing it triggered twice by CC, also burns the codex tokens.
fix: route /codex:rescue through the Agent tool to stop Skill recursi…
fix: drop context: fork from /codex:rescue so the Agent tool is actua…
fix: stop codex-rescue from retrying on Codex errors and hallucinated…
fix: route /codex:rescue through the Agent tool to stop Skill recursi…
fix: route /codex:rescue through the Agent tool to stop Skill recursi…
Sarah20187 commentedon Apr 28, 2026
Still encountering this in opus 4.7. The infinite recursion hasn't gone away, and it’s still burning through tokens at an alarming rate.
rsktash commentedon Apr 29, 2026
No need to install this plugin. I've created skill for reviews
fix: cherry-pick rescue.md routing fix from upstream + bump 1.0.3→1.0.4
Port rescue command routing fix from upstream PR openai#234/openai#235
Sync fork with upstream openai/codex-plugin-cc (1.0.2 → 1.0.6) (#7)
collapse rescue into one user-invoked skill; hide codex-prompting