Image generation belongs inside the coding session
An implementation preview of MendCode Image Gen: gpt-image-2 generation and editing through subscription OAuth, bounded references, durable PNG artifacts, and no separate API-key workflow.
Editorial cover
A story-specific system diagram. Product evidence, when present, appears beside the claims it supports.
Image generation is becoming part of software work. Developers need launch art, diagrams, textures, placeholders, social crops, documentation visuals, and edits to assets that already live in the repo. Sending that work through a separate dashboard breaks the session exactly when the agent finally has enough context to help.
MendCode now has a working feature-branch implementation of an Image Gen tool that lives inside the coding session. The contract is intentionally narrow: use the active Codex or ChatGPT subscription, generate or edit through a real image_gen tool call, persist the result locally, and hand the model an exact file path it can place in the project when the user asks.
The missing tool
A coding agent can already inspect an existing image, reason about layout, edit application code, and place assets in the right directory. The missing link is first-class generation. Without it, the workflow stops at a browser tab, a manual download, and a filename the model never sees.
The right abstraction is not an image button bolted onto chat. It is a tool with the same expectations as every other serious coding tool: explicit availability, bounded inputs, durable output, inspectable failure, and a path back into the repo.
Subscription is the contract
The tool registry exposes image_genonly when the active provider is OpenAI and the stored OpenAI authentication is OAuth. Direct API-key sessions do not receive the tool. That matters because the product promise is simple: if image generation is included in the user's coding subscription, MendCode should use that authenticated path instead of creating a second billing relationship.
Provider and authentication state decide whether the tool exists. Prompt wording does not override that boundary. When the access token is stale, MendCode refreshes it through the existing subscription credentials and forwards the account identity when the OAuth session provides one.
One auth contract
| Concern | Wrong shape | MendCode direction |
|---|---|---|
| Access | Tool appears everywhere and fails later | OpenAI provider plus eligible OAuth session |
| Billing | Separate API key and usage account | Existing Codex subscription path |
| Failure | Fall back to another provider silently | Return the real provider error and preserve trust |
Generation and editing
The implementation covers both generation and editing with gpt-image-2. A prompt with both reference selectors omitted—or an explicit recent-image count of zero—uses the generation endpoint. Absolute local paths or one to five recent conversation images switch the request to editing. Local paths and recent attachments are separate selectors and cannot be combined, so the tool always knows exactly where its references came from.
Up to five references keep the operation bounded. Local files must be supported raster images, stay under 50 MB each, and pass the normal external-directory and read-permission checks. Recent-image edits must find the exact requested count in the conversation. Size, quality, and background remain automatic instead of turning the tool into a low-level image API console.
Workflow diagram
Collect the prompt and bounded references
Generate or edit through the subscription tool
Attach the resulting PNG to the session
An image is an artifact
A generated image does not vanish into a transient response. MendCode validates that the response is actually PNG data, saves it under the managed generated_images/<session>/<tool-call>.png hierarchy, associates metadata with the tool result, and attaches the image inline so later turns can reference the same artifact.
The model also receives the absolute local path. If the image belongs to the product, documentation, or website, the model must copy it into the workspace with a stable descriptive filename and must not overwrite an existing asset unless replacement was explicit. Managed output is evidence and history; the repo path is the product asset.
request + references
-> subscription image tool
-> managed PNG tied to the session
-> inline attachment for the next turn
-> explicit copy into the project when neededNo silent fallbacks
Image systems become untrustworthy when they silently switch models, providers, billing paths, formats, or edit semantics. This implementation does not hide behind fallback behavior. No eligible OAuth session means no tool. Conflicting selectors fail before a request. Non-success responses preserve a bounded provider error, and malformed, empty, invalid-base64, or non-PNG results are rejected instead of being written under a convincing filename.
Release boundary
The feature branch now covers registry visibility, OAuth gating, generation, local-image edits, recent-conversation edits, selector conflicts, durable persistence, inline attachments, prompt guidance, and invalid-response handling with focused tests. That is implementation evidence, not release evidence. Merge, release integration, and a live subscription smoke test still gate the public claim that the path is available to users.
Image generation becomes a coding feature when the artifact can move from intent to session to repo without leaving the harness.