fix: route /codex:rescue through the Agent tool to stop Skill recursion (#234)

[pengyou200902]

Fixes #234.

What was broken

/codex:rescue was marked context: fork, so the command body ran inside a forked general-purpose subagent. The body said:

Route this request to the codex:codex-rescue subagent.

When the main Claude Code agent called Skill(codex:rescue) programmatically (as opposed to the user typing the slash command), the forked runner read that ambiguous prose and guessed the transport. It tried Skill(codex:codex-rescue) — unknown skill — then fell back to Skill(codex:rescue), which re-entered this same command and recursed until the user cancelled. No Codex job was ever created.

The user-facing symptom, quoted from the issue:

UI appears frozen; no Codex job is created… After ~3+ minutes, user must cancel manually.

Why the fix is two coordinated changes and not one

The issue's "Suggested fix" section lists two options:

1. Name the transport explicitly (use the Agent tool).
2. Restrict allowed-tools to exclude Skill.

In practice, neither alone is sufficient. Forked general-purpose subagents do not expose the Agent tool, so instructing the fork to "use Agent" just trades the hang for a clean failure — the main agent then retries on its own. The minimum fix is therefore two coordinated changes:

• Drop context: fork. The command body now runs inline in the calling agent's context, where the Agent tool is in scope.
• Name the transport explicitly. Invoke codex:codex-rescue via Agent(subagent_type: "codex:codex-rescue"), add Agent to allowed-tools, and call out that Skill(codex:codex-rescue) / Skill(codex:rescue) are not valid paths.

Everything else in rescue.md — resume-candidate check, --background / --wait / --resume / --fresh handling, operating rules, model/effort pass-through — is unchanged. agents/codex-rescue.md and skills/codex-cli-runtime/SKILL.md are not touched.

Diff

plugins/codex/commands/rescue.md: 4 lines changed (one frontmatter swap, two body sentences rewritten).

-context: fork
-allowed-tools: Bash(node:*), AskUserQuestion
+allowed-tools: Bash(node:*), AskUserQuestion, Agent

-Route this request to the `codex:codex-rescue` subagent.
+Invoke the `codex:codex-rescue` subagent via the `Agent` tool
+(`subagent_type: "codex:codex-rescue"`), forwarding the raw user
+request as the prompt.
+`codex:codex-rescue` is a subagent, not a skill — do not call
+`Skill(codex:codex-rescue)` … or `Skill(codex:rescue)` (that
+re-enters this command and hangs the session). The command runs
+inline so the `Agent` tool stays in scope; forked general-purpose
+subagents do not expose it.

tests/commands.test.mjs: pin the new allowed-tools, pin the explicit subagent_type: "codex:codex-rescue" prose, pin the Skill(codex:codex-rescue) ban, and assert context: fork is absent. Total +9 / −1.

Not in scope

During iteration on this fix I observed adjacent duplicate-task-call patterns inside codex:codex-rescue (model-name drift retried on Codex 4xx, long prompts failing on zsh shell-quoting, main-agent retry on upstream failure). Those are separate bugs and deserve separate issues and separate PRs where they can be discussed on their own merits. I deliberately kept this PR scoped to #234's routing hang to keep the diff small, reviewable, and directly tied to the filed issue.

Test plan

• node --test tests/commands.test.mjs -t "rescue command absorbs continue semantics" passes.
• Negative: with the pre-fix rescue.md restored, the new assertions fail on allowed-tools → Agent missing, then would also fail on the subagent_type and no-context: fork assertions.
• node --test tests/commands.test.mjs as a whole: 7/8 — the one failure is a pre-existing result "$ARGUMENTS" quoting assertion unrelated to rescue (introduced in fix: quote $ARGUMENTS in cancel, result, and status commands #168, also fails on pristine upstream/main).
• Live end-to-end requires a fresh Claude Code session with this branch's plugin installed; not runnable from the session that prepared this PR.

Commits

One commit: cd4cb60 fix: route /codex:rescue through the Agent tool to stop Skill recursion (#234).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eb24951c89

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c582eda025

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[pengyou200902]

A note on the context: fork removal in case reviewers wonder whether that layer is load-bearing:

Original topology (with context: fork): /codex:rescue spawned a general-purpose fork; that fork was supposed to dispatch to codex:codex-rescue; Codex ran inside the codex:codex-rescue subagent. Two layers of isolation.

The bug: forked general-purpose subagents do not expose the Agent tool, so from inside the fork there is no way to reach the codex:codex-rescue subagent — which is the single place this plugin defines the task forwarder. The fork's only option is to guess a Skill path, which is exactly what drove the recursion in #234.

After the fix: the command body runs inline in the caller, which does have Agent, so it calls Agent(subagent_type: "codex:codex-rescue") directly. The codex:codex-rescue subagent is still its own Agent-tool subagent with its own sandbox, its own tool set, and its own tool_result boundary — Codex execution isolation is preserved, just one layer down instead of two.

Consistency check: every other command in plugins/codex/commands/ already runs inline — review, adversarial-review, setup, status, result, cancel. rescue.md was the only one with context: fork, and review / adversarial-review do comparable or more orchestration. So the fork was an outlier, not a pattern.

Trade-off acknowledged: the calling agent now sees the rescue.md body and the task-resume-candidate / AskUserQuestion / Agent tool transcripts in its own context during one rescue call, rather than behind a fork. That's a small amount of additional context usage per invocation, matching every other command in this plugin.

Alternative considered: keeping the fork and having it call Bash(node codex-companion.mjs task …) directly would sidestep the missing-Agent issue without removing context: fork, but it duplicates the forwarder logic that lives in agents/codex-rescue.md, creates two sources of truth, and is a structurally larger diff. Happy to switch to that shape if the maintainers would rather keep the fork — just let me know.