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
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).
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.
- 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
- 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/.
- 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.
The
taskruntime behind/codex:rescueandcodex-companion.mjs taskdrives acodex app-serverturn. When the prompt asks Codex to generate an image, the job stays in thestartingphase and never finishes. I ran one with--writefor over seven minutes: no file, no error, and/codex:statusreportedrunning/startingthe whole time. The same prompt throughcodex execwrites the PNG in under a minute.Repro
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).node scripts/codex-companion.mjs status <job-id>keeps returningrunning, phasestarting, for as long as you wait.cancelis the only way out.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/nullsaves 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.mjssends a text-onlyUserInput([{ type: "text", text: prompt }]) into acodex app-serverturn.codex app-serveris marked experimental, and the built-in image generation thatcodex execexposes 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
startingwith no output. As it stands the job hangs silently and the only trace is candidate files left in~/.codex/generated_images/.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 throughcodex execunder 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 execbehind a flag. I'd rather hear which approach you'd accept before I start, so I build the right one.