* fix: route /codex:rescue through the Agent tool to stop Skill recursion (#234)
`/codex:rescue` previously combined two things that together caused a hang:
- `context: fork` in the frontmatter, which spawns a `general-purpose`
subagent for the command body.
- Body prose "Route this request to the `codex:codex-rescue` subagent."
without naming the transport.
When the main agent called `Skill(codex:rescue)` programmatically, the
fork resolved the ambiguous prose by trying `Skill(codex:codex-rescue)`
(unknown skill) and then falling back to `Skill(codex:rescue)`, which
re-entered this command and hung the session until the user cancelled.
No Codex job was ever created.
Naming the transport as `Agent(codex:codex-rescue)` alone is not enough:
forked general-purpose subagents do not expose the `Agent` tool, so the
forked runner cannot reach the subagent that way either. The minimal fix
is therefore two coordinated changes:
- Drop `context: fork` so the command body runs inline in the calling
agent's context, where `Agent` is in scope.
- Say explicitly "use the `Agent` tool with `subagent_type:
"codex:codex-rescue"`", and call out that `Skill(codex:codex-rescue)`
and `Skill(codex:rescue)` are not valid routing paths. Add `Agent`
to `allowed-tools` so the call does not prompt for permission.
Everything else in rescue.md (resume-candidate check, flag handling,
background/foreground semantics, operating rules) is unchanged. The
`codex:codex-rescue` subagent itself is unchanged.
Tests pin the new allow-list, the explicit `subagent_type`, the ban on
`Skill(codex:codex-rescue)`, and the absence of `context: fork`. The
existing "run the `codex:codex-rescue` subagent in the background"
assertion continues to hold since that sentence still reads correctly
with the Agent-tool transport.
Fixesopenai/codex-plugin-cc#234
* test: match quoted result and cancel command arguments
---------
Co-authored-by: Dominik Kundel <dkundel@openai.com>
bb38412a67