openclaw - 💡(How to fix) Fix Feature: expose Responses image generation IDs for iterative image edits

Summary

OpenClaw's image_generate provider already uses the OpenAI Responses API + hosted image_generation tool for the OpenAI Codex OAuth route, but it does not preserve or expose the response/tool-call identifiers needed for iterative image editing.

As a result, users cannot build a ChatGPT-like image editing flow via OpenClaw, where a generated image can be refined in follow-up turns using previous_response_id, action: edit, or image generation call/image IDs. The only available workflow is to save the generated PNG locally and pass it back as a reference image, which is not equivalent to Responses API stateful continuation.

Why this matters

For product/design workflows, especially multi-image commerce/detail-page work, consistency across iterations is critical. Stateless reference-image re-upload often causes style drift and loses the benefits of the Responses API conversation/tool context.

Expected capability:

1. Generate an image through image_generate.
2. Receive metadata such as response.id and/or image_generation_call.id.
3. Call image_generate again with previousResponseId and action: edit or equivalent.
4. Let the OpenAI Responses API continue from the previous image context instead of forcing a full stateless re-upload.

Current behavior observed in installed OpenClaw 2026.5.4

Code inspection of the bundled OpenAI image provider shows that the Codex OAuth route posts to /responses with the hosted image tool:

• file: dist/image-generation-provider-DABFqnZ8.js
• function: generateOpenAICodexImage(...)
• request shape includes:
  • model: "gpt-5.5"
  • tools: [{ type: "image_generation", model, ... }]
  • tool_choice: { type: "image_generation" }
  • stream: true
  • store: false

The response parser also sees Responses API events:

• response.output_item.done
• response.completed
• output items where entry.type === "image_generation_call"

However, extractCodexImageGenerationResult(...) currently returns only:

• generated images
• model
• metadata containing usage and toolUsage

The image object built by toCodexImage(...) preserves:

• buffer
• mimeType
• fileName
• optional revisedPrompt

It does not preserve/expose:

• completedResponse.response.id
• image_generation_call.id
• any image/file IDs that could be reused
• any continuation handle usable as previous_response_id

At the tool boundary, image_generate saves the media and returns mostly:

• MEDIA:/.../tool-image-generation/*.png
• details.paths
• details.metadata
• optional details.revisedPrompts

The tool schema also does not currently expose parameters such as:

• previousResponseId
• conversation / conversation id
• action: auto | generate | edit
• image generation call id / image id reuse
• store control

Expected behavior

Please consider adding an opt-in stateful image editing path for OpenAI Responses image generation, for example:

Return metadata

Expose safe continuation metadata in image_generate.details, such as:

• responseId
• imageGenerationCallIds
• maybe revisedPrompts
• usage/tool usage as today

Add input options

Add OpenAI-specific or generic options such as:

• previousResponseId
• action: "auto" | "generate" | "edit"
• store: true | false or an OpenClaw-managed continuation mode

Preserve backward compatibility

Default behavior can remain stateless, with continuation disabled unless requested, e.g.:

• store remains false by default
• IDs only surfaced when available
• previousResponseId only used when explicitly passed

Related but not identical issue

#75074 is related at the Responses API surface level because it discusses built-in tool call visibility, including image_generation_call. However, this request is narrower/different: enable image_generate itself to preserve and reuse Responses image generation continuation IDs for iterative image editing.

Use case

A user generates a product hero image, then wants to say:

• "keep the product and layout, only change the background lighting"
• "make this module match the previous visual system"
• "use the same style master and revise only the copy area"

The current OpenClaw workflow requires re-uploading a generated PNG as a reference image. That works as image-to-image, but it is not the same as official Responses API continuation and tends to drift across multi-step design workflows.