Skip to content

Fix Codex image generation output handling#1

Open
vekexasia wants to merge 1 commit into
capyup:mainfrom
vekexasia:fix-codex-image-generation-output
Open

Fix Codex image generation output handling#1
vekexasia wants to merge 1 commit into
capyup:mainfrom
vekexasia:fix-codex-image-generation-output

Conversation

@vekexasia
Copy link
Copy Markdown

Summary

  • Make image_generation execute as a normal Pi function tool instead of relying on native tool rewrite support.
  • Call the Codex Responses image generation endpoint, parse image_generation_call.result, and save the generated PNG under .pi/openai-codex-images/ with latest.png mirror.
  • Keep dynamic routing for view_image and update docs/skill text to describe the new behavior.

Why

In current Pi, native image_generation_call stream items from Codex are not converted into agent-visible image/tool output. The previous rewrite-based implementation can therefore result in an empty assistant response while the model believes the image was generated.

This patch keeps the fix inside this extension by handling the image generation response directly.

Verification

  • npm pack --dry-run
  • tsx -e "import('./extensions/codex-image.ts').then(()=>console.log('import-ok'))"
  • Local Pi CLI smoke test against openai-codex/gpt-5.5 verified:
    • assistant called image_generation
    • tool result had isError: false
    • .pi/openai-codex-images/latest.png was created as a valid PNG

@vekexasia
Copy link
Copy Markdown
Author

A bit more context from the repro/debugging session:

  • A direct Codex request with { type: "image_generation", output_format: "png" } does return an image_generation_call item with a large base64 result.
  • Pi's current openai-responses-shared parser ignores that item type, so the old native-rewrite approach can complete with an empty assistant message and no local file.
  • I chose an extension-local fix here rather than requiring a Pi core parser change, since this package already promises to save generated outputs locally.

One thing worth reviewing carefully: this reads the existing ~/.pi/agent/auth.json OpenAI Codex OAuth token/account id because normal tool execution does not appear to receive the resolved provider API key. If there is a better extension API for accessing the current provider credentials, I can adjust the PR to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant