task/rescue hangs at "starting" for image-generation prompts

The task runtime behind /codex:rescue and codex-companion.mjs task drives a codex app-server turn. When the prompt asks Codex to generate an image, the job stays in the starting phase and never finishes. I ran one with --write for over seven minutes: no file, no error, and /codex:status reported running / starting the whole time. The same prompt through codex exec writes the PNG in under a minute.

Repro

1. node scripts/codex-companion.mjs task --write "Use your built-in image generation to create a 512x512 cream square with a small icon centered. Save the PNG to /tmp/codex-img-test.png. Do not write code." (or the matching /codex:rescue).
2. node scripts/codex-companion.mjs status <job-id> keeps returning running, phase starting, for as long as you wait. cancel is the only way out.
3. For comparison, codex exec --skip-git-repo-check --sandbox workspace-write -C /tmp "Use your built-in image generation ... Save the PNG to /tmp/codex-img-test2.png. Do not write code." < /dev/null saves the PNG in about 30 to 60 seconds.

Versions: codex-plugin-cc 1.0.4, codex-cli 0.136.0, Node v22.16.0, macOS, ChatGPT subscription auth.

What looks like the cause

lib/codex.mjs sends a text-only UserInput ([{ type: "text", text: prompt }]) into a codex app-server turn. codex app-server is marked experimental, and the built-in image generation that codex exec exposes does not appear to be reachable inside the app-server turn. A prompt that asks for an image then has no tool to call, so the turn never progresses instead of erroring out.

What I'd like to see

1. A turn that cannot proceed should time out or return a clear error rather than sitting in starting with no output. As it stands the job hangs silently and the only trace is candidate files left in ~/.codex/generated_images/.
2. A managed path for image generation. Today the only working route is raw codex exec. Running a few of those at once contends for the Codex websocket and returns 403/429 while still spending quota, which is the exact failure the companion's serialized job runtime is built to avoid. Routing image-style tasks through codex exec under the same job tracking, or enabling whatever app-server feature backs imagegen, would cover it.

I'm willing to do the work and send a PR for either part, the graceful-failure fix or wiring image tasks through codex exec behind a flag. I'd rather hear which approach you'd accept before I start, so I build the right one.

Start with lib/codex.mjs and the task entry point in scripts/codex-companion.mjs; trace how an app-server turn moves out of the starting phase and compare it with the working codex exec path. Reproduce the image-generation prompt and inspect the existing job status and cancellation handling. Done means the task no longer hangs silently and either reports a clear failure or provides a managed image-generation route.