Summary
Calling the codex:codex-rescue Agent from Claude Code with a large prompt (~6 KB in my repro) returns the generic Claude Code "user denied" rejection without ever showing the user a permission prompt. Smaller prompts work normally. Because the rejection looks identical to a deliberate user denial, Claude Code goes silent waiting for the user, and the user is left unable to tell that anything is wrong.
The same issue affects any planning the plugin would need to do — Claude Code can't recover, can't retry with a smaller prompt, and can't tell the user what happened, because the failure mode masquerades as a user action.
Steps to reproduce
- Claude Code session with the plugin installed and
codex:codex-rescue available as a subagent (verified via the agent list).
- From Claude Code, dispatch the agent with a large prompt: about 6 KB of text in my case (a multi-section investigation brief). The prompt size threshold is not yet pinned — smaller prompts (echo "hello", a few hundred bytes) succeed.
- Observe: Claude Code receives the standard rejection message immediately (
The user doesn't want to proceed with this tool use. The tool use was rejected ...). No permission prompt appears in the user's UI.
Expected
The plugin should either accept the prompt and run, or return a structured error to Claude Code that names the actual reason (e.g. "prompt exceeds N bytes", "content filtered", etc.). Claude Code can then either retry with a trimmed prompt, hand it off to disk + a small pointer, or surface the failure to the user explicitly.
Actual
The error message Claude Code receives is the literal "user denied tool use" text — same wording as if the user had clicked "Deny" on a permission prompt. There is no signal that the rejection came from inside the plugin rather than from the user.
Workaround that succeeded for me
Writing the brief to a file on disk and passing only Read /tmp/brief.md and follow the instructions there as the prompt. The agent then reads the brief itself, and dispatch succeeds. This confirms the failure scales with prompt size, not content semantics.
Why it matters
This is roughly the worst category of failure mode: the plugin appears to silently use the host Claude Code's "user denied" plumbing for what is actually a plugin-side rejection. Everything downstream (Claude Code's wait-for-user behavior, the user's mental model of what just happened) breaks. The fix shape doesn't have to be heavy — even returning a distinct error string ("Codex plugin: prompt exceeds X bytes" or similar) would let Claude Code respond appropriately.
Environment
- Claude Code session, current Codex plugin version
- Linux/WSL2
- ChatGPT-login auth (
codex login status reports "Logged in using ChatGPT")
- Codex CLI 0.125.0
Summary
Calling the
codex:codex-rescueAgent from Claude Code with a large prompt (~6 KB in my repro) returns the generic Claude Code "user denied" rejection without ever showing the user a permission prompt. Smaller prompts work normally. Because the rejection looks identical to a deliberate user denial, Claude Code goes silent waiting for the user, and the user is left unable to tell that anything is wrong.The same issue affects any planning the plugin would need to do — Claude Code can't recover, can't retry with a smaller prompt, and can't tell the user what happened, because the failure mode masquerades as a user action.
Steps to reproduce
codex:codex-rescueavailable as a subagent (verified via the agent list).The user doesn't want to proceed with this tool use. The tool use was rejected ...). No permission prompt appears in the user's UI.Expected
The plugin should either accept the prompt and run, or return a structured error to Claude Code that names the actual reason (e.g. "prompt exceeds N bytes", "content filtered", etc.). Claude Code can then either retry with a trimmed prompt, hand it off to disk + a small pointer, or surface the failure to the user explicitly.
Actual
The error message Claude Code receives is the literal "user denied tool use" text — same wording as if the user had clicked "Deny" on a permission prompt. There is no signal that the rejection came from inside the plugin rather than from the user.
Workaround that succeeded for me
Writing the brief to a file on disk and passing only
Read /tmp/brief.md and follow the instructions thereas the prompt. The agent then reads the brief itself, and dispatch succeeds. This confirms the failure scales with prompt size, not content semantics.Why it matters
This is roughly the worst category of failure mode: the plugin appears to silently use the host Claude Code's "user denied" plumbing for what is actually a plugin-side rejection. Everything downstream (Claude Code's wait-for-user behavior, the user's mental model of what just happened) breaks. The fix shape doesn't have to be heavy — even returning a distinct error string ("Codex plugin: prompt exceeds X bytes" or similar) would let Claude Code respond appropriately.
Environment
codex login statusreports "Logged in using ChatGPT")