codex-imagegen-free-reference

name

codex-imagegen-free-reference

description

Generate or edit raster images through Codex API direct image generation with local reference-image support, Codex-auth discovery, and copy-based project output handling. Use when Codex should create a brand-new bitmap image, transform an existing image, or derive visual variants from references. Do not use when the task is better handled by editing existing SVG/vector/code-native assets, extending an established icon or logo system, or building the visual directly in HTML/CSS/canvas.

codex-imagegen-free-reference

Generates or edits images for the current project (for example website assets, game assets, UI mockups, product mockups, wireframes, logo design, photorealistic images, or infographics).

Top-level modes and rules

This skill has exactly three top-level modes:

• Codex API direct mode (recommended when available): scripts/codex_image_gen.py calls the Codex Responses hosted-tool route with Codex auth and supports local reference images. It does not require OPENAI_API_KEY. The Codex Image API generation/edit route remains available with --transport image-api.
• Default built-in tool mode: built-in image_gen tool for normal image generation and editing when the harness exposes it. Does not require OPENAI_API_KEY, but the tool is harness-provided rather than directly scriptable from this package.
• Fallback OpenAI Image API CLI mode: scripts/image_gen.py CLI. Use when the user explicitly asks for the public OpenAI API/model path, or after the user explicitly confirms a true model-native transparency fallback with gpt-image-1.5. Requires OPENAI_API_KEY.

Within Codex API direct mode, the CLI exposes one command path:

• scripts/codex_image_gen.py

Within OpenAI Image API fallback, the CLI exposes three subcommands:

• generate
• edit
• generate-batch

Rules:

• Use scripts/codex_image_gen.py by default when Codex auth is available, especially for local reference images and project-bound output paths.
• Codex API direct mode defaults to https://chatgpt.com/backend-api/codex/responses with the hosted Responses image_generation tool.
• Codex API direct mode exposes image controls through scripts/codex_image_gen.py: --model, --reasoning-effort, --image-model, --size, --quality, --background, --output-format, --output-compression, --moderation, --action, --partial-images, --timeout, --input-fidelity, --mask, and --hide-response-details. Use --transport image-api only when the Codex Image API generation/edit route is specifically needed.
• Use the built-in image_gen tool only when the harness exposes it and the task is simpler to perform in the conversation context than through the scriptable Codex API direct path.
• Use the OpenAI Image API fallback scripts/image_gen.py only when the user explicitly asks for the public OpenAI API/model path or confirms a true/native transparency fallback. This path requires OPENAI_API_KEY.
• Do not create one-off SDK runners for routine image generation. Use scripts/codex_image_gen.py for Codex-auth work or scripts/image_gen.py for explicit OpenAI API fallback work.
• For Codex API direct mode, generated originals and logs are saved under the selected Codex home's generated_images_free_reference/. The default Responses transport uses the OpenAI SDK and writes append-only redacted request/response event logs; the optional Image API transport writes append-only redacted JSONL event logs. Original filenames use <uuid>-<name>.<ext>, and logs use <uuid>-<name>.<ext>.log. Project-local placement is done by copying the selected original with --copy-to. If --auth-json is provided, that auth file and its parent directory are used. Otherwise auth discovery checks $CODEX_HOME/auth.json first, then ~/.codex/auth.json.
• If the user explicitly asks for a transparent image/background, prefer the chroma-key workflow first. Native transparency requires an explicit supported image model plus --background transparent, or the OpenAI Image API fallback after explicit user confirmation.
• Never silently switch from Codex API direct or CLI gpt-image-2 to CLI gpt-image-1.5. Treat this as a model/path downgrade and ask the user before doing it, unless the user has already explicitly requested gpt-image-1.5, scripts/image_gen.py, or OpenAI API fallback.
• If a transparent request appears too complex for clean chroma-key removal, asks for true/native transparency, or local removal fails validation, explain that native transparency requires an explicit supported image model with --background transparent and a transparent-capable output format. Use the OpenAI API fallback only after the user confirms that API-key path.
• The word batch by itself does not mean OpenAI API fallback. For many Codex-auth assets, run scripts/codex_image_gen.py once per distinct prompt or use an external job wrapper chosen by the user.

Codex API direct save-path policy:

• Save generated originals under the selected Codex home's generated_images_free_reference/ by default.
• Save logs under the same generated_images_free_reference/ directory by default. Logs are append-only: write start metadata once, then append response, failure, and CLI-message events without rewriting earlier records. Start metadata includes the endpoint, transport, output path, invocation, ordered reference and mask paths, and request payload. Invocation metadata keeps the working directory, a platform-quoted equivalent command, and the complete argument array. Input paths keep both the supplied value and the resolved absolute path. Responses event blocks include a separate UTC logged_at: line; Image API JSONL records use top-level logged_at, event, and data fields. Image API logs redact base64 image payloads; Responses logs keep event structure while redacting image payloads.
• File names must combine a UUID and a human-readable name: <uuid>-<name>.<ext>.
• Log names must use the generated image name with .log appended: <uuid>-<name>.<ext>.log.
• If the user names a project destination, copy the selected output there with --copy-to; keep the Codex-home original as the generated source.
• If the image is meant for the current project, copy the final selected image into the workspace before finishing.
• If the image is only for preview or brainstorming, the file can remain under the selected Codex home's generated_images_free_reference/.
• Never leave a project-referenced asset only at the default Codex-home path.
• Do not overwrite an existing asset unless the user explicitly asked for replacement; otherwise create a sibling versioned filename such as hero-v2.png or item-icon-edited.png.

Shared prompt guidance for both modes lives in references/prompting.md and references/sample-prompts.md.

Fallback-only docs/resources for CLI mode:

• references/cli.md
• references/image-api.md
• references/codex-network.md
• scripts/image_gen.py

Local post-processing helper:

• $CODEX_HOME/skills/codex-imagegen-free-reference/scripts/remove_chroma_key.py: removes a flat chroma-key background from a generated image and writes a PNG/WebP with alpha. Prefer auto-key sampling, soft matte, and despill for antialiased edges.

Python environment

• Use the skill-local virtual environment at $CODEX_HOME/skills/codex-imagegen-free-reference/.venv for every Python script in this skill.
• If the environment does not exist, create it first:

  SKILL_ROOT="${CODEX_HOME:-$HOME/.codex}/skills/codex-imagegen-free-reference"
  uv venv "$SKILL_ROOT/.venv"
  

• Install packages into that exact environment:

  uv pip install --python "$SKILL_ROOT/.venv/bin/python" openai pillow
  

• Run scripts with the environment's Python executable explicitly:

  "$SKILL_ROOT/.venv/bin/python" "$SKILL_ROOT/scripts/codex_image_gen.py" ...
  

• On Windows, use $env:CODEX_HOME\skills\codex-imagegen-free-reference\.venv\Scripts\python.exe.
• Do not use bare python, uv run python, uv pip install --system, uv tool, a user/system interpreter, a uv-managed interpreter directly, or a project-local virtual environment for this skill.

When to use

• Generate a new image (concept art, product shot, cover, website hero)
• Generate a new image using one or more reference images for style, composition, or mood
• Edit an existing image (inpainting, lighting or weather transformations, background replacement, object removal, compositing, transparent background)
• Produce many assets or variants for one task

When not to use

• Extending or matching an existing SVG/vector icon set, logo system, or illustration library inside the repo
• Creating simple shapes, diagrams, wireframes, or icons that are better produced directly in SVG, HTML/CSS, or canvas
• Making a small project-local asset edit when the source file already exists in an editable native format
• Any task where the user clearly wants deterministic code-native output instead of a generated bitmap

Decision tree

Think about two separate questions:

1. Intent: is this a new image or an edit of an existing image?
2. Execution strategy: is this one asset or many assets/variants?

Intent:

• If the user wants to modify an existing image while preserving parts of it, treat the request as edit.
• If the user provides images only as references for style, composition, mood, or subject guidance, treat the request as generate.
• If the user provides no images, treat the request as generate.

Built-in edit semantics:

• Built-in edit mode is for images already visible in the conversation context, such as attached images or images generated earlier in the thread.
• If the user wants to edit a local image file with the built-in tool, first load it with built-in view_image tool so the image is visible in the conversation context, then proceed with the built-in edit flow.
• Do not promise arbitrary filesystem-path editing through the built-in tool.
• If a local file still needs direct file-path control, masks, or other explicit CLI-only parameters, use the explicit CLI fallback only when the user asks for it.
• For edits, preserve invariants aggressively and save non-destructively by default.

Execution strategy:

• In the built-in default path, produce many assets or variants by issuing one image_gen call per requested asset or variant.
• In the CLI fallback path, use the CLI generate-batch subcommand only when the user explicitly chose CLI mode and needs many prompts/assets.
• For many distinct assets, do not use n as a substitute for separate prompts. n is for variants of one prompt; distinct assets need distinct built-in calls or distinct CLI generate-batch jobs.

Assume the user wants a new image unless they clearly ask to change an existing one.

Workflow

1. Decide the top-level mode: Codex API direct by default when Codex auth is available; built-in only when the harness-exposed tool is simpler; OpenAI API fallback only when explicitly requested or confirmed.
2. Decide the intent: generate from prompt/references, or edit an existing visible/conversation image. For local file references, prefer Codex API direct with --reference.
3. Decide whether the output is preview-only or meant to be consumed by the current project.
4. Decide the execution strategy: one scripts/codex_image_gen.py call per distinct Codex-auth asset, built-in calls only for harness-native work, or OpenAI API generate-batch only after explicit fallback opt-in.
5. Collect inputs up front: prompt(s), exact text (verbatim), constraints/avoid list, and any input images.
6. For every input image, label its role explicitly:
   • reference image
   • edit target
   • supporting insert/style/compositing input
7. If the edit target is only on the local filesystem and you are staying on the built-in path, inspect it with view_image first so the image is available in conversation context.
8. If the user asked for a photo, illustration, sprite, product image, banner, or other explicitly raster-style asset, use Codex API direct or built-in image generation rather than substituting SVG/HTML/CSS placeholders. If the request is for an icon, logo, or UI graphic that should match existing repo-native SVG/vector/code assets, prefer editing those directly instead.
9. Augment the prompt based on specificity:
   • If the user's prompt is already specific and detailed, normalize it into a clear spec without adding creative requirements.
   • If the user's prompt is generic, add tasteful augmentation only when it materially improves output quality.
10. Run the skill-local interpreter for Codex-auth generation/edit, including local references: "$SKILL_ROOT/.venv/bin/python" "$SKILL_ROOT/scripts/codex_image_gen.py" .... On Windows, use the matching .venv\Scripts\python.exe.
11. For transparent-output requests, follow the transparent image guidance below: generate on a flat chroma-key background, copy the selected output into the workspace or tmp/imagegen/, run the installed $CODEX_HOME/skills/codex-imagegen-free-reference/scripts/remove_chroma_key.py helper, and validate the alpha result before using it. If this path looks unsuitable or fails, ask before switching to CLI gpt-image-1.5.
12. Inspect outputs and validate: subject, style, composition, text accuracy, and invariants/avoid items.
13. Iterate with a single targeted change, then re-check.
14. For preview-only work, the underlying file may remain at $CODEX_HOME/generated_images_free_reference/.
15. For project-bound work, copy the selected artifact into the workspace with --copy-to and update any consuming code or references. Never leave a project-referenced asset only at the default Codex-home path.
16. For batches or multi-asset requests, persist every requested deliverable final in the workspace unless the user explicitly asked to keep outputs preview-only. Discarded variants do not need to be kept unless requested.
17. For Codex API direct controls such as model, quality, size, input_fidelity, masks, output format, compression, and partial images, use references/codex-direct.md. If the user explicitly chooses or confirms the OpenAI API fallback, use the fallback-only docs for API-key setup and fallback CLI behavior.
18. Always report the final saved path(s) for any workspace-bound asset(s), plus the final prompt or prompt set and whether Codex API direct, built-in, or OpenAI API fallback mode was used.

Transparent image requests

Transparent-image requests still use built-in image_gen first. Because the built-in tool does not expose a true transparent-background control, create a removable chroma-key source image and then convert the key color to alpha locally.

Default sequence:

1. Use built-in image_gen to generate the requested subject on a perfectly flat solid chroma-key background.
2. Choose a key color that is unlikely to appear in the subject: default #00ff00, use #ff00ff for green subjects, and avoid #0000ff for blue subjects.
3. After generation, copy the selected source image from $CODEX_HOME/generated_images_free_reference/... into the workspace or tmp/imagegen/.
4. Run the installed helper path, not a project-relative script path:

   "${CODEX_HOME:-$HOME/.codex}/skills/codex-imagegen-free-reference/.venv/bin/python" \
     "${CODEX_HOME:-$HOME/.codex}/skills/codex-imagegen-free-reference/scripts/remove_chroma_key.py" \
     --input <source> \
     --out <final.png> \
     --auto-key border \
     --soft-matte \
     --transparent-threshold 12 \
     --opaque-threshold 220 \
     --despill
   

5. Validate that the output has an alpha channel, transparent corners, plausible subject coverage, and no obvious key-color fringe. If a thin fringe remains, retry once with --edge-contract 1; use --edge-feather 0.25 only when the edge is visibly stair-stepped and the subject is not shiny or reflective.
6. Save the final alpha PNG/WebP in the project if the asset is project-bound. Never leave a project-referenced transparent asset only under $CODEX_HOME/*.

Prompt transparent requests like this:

Create the requested subject on a perfectly flat solid #00ff00 chroma-key background for background removal.
The background must be one uniform color with no shadows, gradients, texture, reflections, floor plane, or lighting variation.
Keep the subject fully separated from the background with crisp edges and generous padding.
Do not use #00ff00 anywhere in the subject.
No cast shadow, no contact shadow, no reflection, no watermark, and no text unless explicitly requested.

Do not automatically use native transparency instead of chroma keying. Ask the user first when the user asks for true/native transparency, when local removal fails validation, or when the requested image is complex: hair, fur, feathers, smoke, glass, liquids, translucent materials, reflective objects, soft shadows, realistic product grounding, or subject colors that conflict with all practical key colors.

Use a concise confirmation like:

This likely needs true native transparency. The default path uses a chroma-key background plus local removal, but native transparency requires an explicit supported image model, `--background transparent`, and PNG or WebP output. Should I use that native transparency path instead?

Prompt augmentation

Reformat user prompts into a structured, production-oriented spec. Make the user's goal clearer and more actionable, but do not blindly add detail.

Treat this as prompt-shaping guidance, not a closed schema. Use only the lines that help, and add a short extra labeled line when it materially improves clarity.

Specificity policy

Use the user's prompt specificity to decide how much augmentation is appropriate:

• If the prompt is already specific and detailed, preserve that specificity and only normalize/structure it.
• If the prompt is generic, you may add tasteful augmentation when it will materially improve the result.

Allowed augmentations:

• composition or framing hints
• polish level or intended-use hints
• practical layout guidance
• reasonable scene concreteness that supports the stated request

Not allowed augmentations:

• extra characters or objects that are not implied by the request
• brand names, slogans, palettes, or narrative beats that are not implied
• arbitrary side-specific placement unless the surrounding layout supports it

Use-case taxonomy (exact slugs)

Classify each request into one of these buckets and keep the slug consistent across prompts and references.

Generate:

• photorealistic-natural — candid/editorial lifestyle scenes with real texture and natural lighting.
• product-mockup — product/packaging shots, catalog imagery, merch concepts.
• ui-mockup — app/web interface mockups and wireframes; specify the desired fidelity.
• infographic-diagram — diagrams/infographics with structured layout and text.
• scientific-educational — classroom explainers, scientific diagrams, and learning visuals with required labels and accuracy constraints.
• ads-marketing — campaign concepts and ad creatives with audience, brand position, scene, and exact tagline/copy.
• productivity-visual — slide, chart, workflow, and data-heavy business visuals.
• logo-brand — logo/mark exploration, vector-friendly.
• illustration-story — comics, children’s book art, narrative scenes.
• stylized-concept — style-driven concept art, 3D/stylized renders.
• historical-scene — period-accurate/world-knowledge scenes.

Edit:

• text-localization — translate/replace in-image text, preserve layout.
• identity-preserve — try-on, person-in-scene; lock face/body/pose.
• precise-object-edit — remove/replace a specific element (including interior swaps).
• lighting-weather — time-of-day/season/atmosphere changes only.
• background-extraction — transparent background / clean cutout. Use built-in image_gen with chroma-key removal first for simple opaque subjects; ask before using CLI true transparency for complex subjects.
• style-transfer — apply reference style while changing subject/scene.
• compositing — multi-image insert/merge with matched lighting/perspective.
• sketch-to-render — drawing/line art to photoreal render.

Shared prompt schema

Use the following labeled spec as shared prompt scaffolding for both top-level modes:

Use case: <taxonomy slug>
Asset type: <where the asset will be used>
Primary request: <user's main prompt>
Input images: <Image 1: role; Image 2: role> (optional)
Scene/backdrop: <environment>
Subject: <main subject>
Style/medium: <photo/illustration/3D/etc>
Composition/framing: <wide/close/top-down; placement>
Lighting/mood: <lighting + mood>
Color palette: <palette notes>
Materials/textures: <surface details>
Text (verbatim): "<exact text>"
Constraints: <must keep/must avoid>
Avoid: <negative constraints>

Notes:

• Asset type and Input images are prompt scaffolding, not dedicated CLI flags.
• Scene/backdrop refers to the visual setting. It is not the same as an execution background parameter, which controls output transparency behavior.
• Execution notes such as Quality:, Input fidelity:, masks, output format, compression, partial images, and output paths belong to the selected execution path. They are supported by the Codex direct CLI and fallback CLI where documented, but they are not built-in image_gen tool arguments.

Augmentation rules:

• Keep it short.
• Add only the details needed to improve the prompt materially.
• For edits, explicitly list invariants (change only X; keep Y unchanged).
• If any critical detail is missing and blocks success, ask a question; otherwise proceed.

Examples

Generation example (hero image)

Use case: product-mockup
Asset type: landing page hero
Primary request: a minimal hero image of a ceramic coffee mug
Style/medium: clean product photography
Composition/framing: wide composition with usable negative space for page copy if needed
Lighting/mood: soft studio lighting
Constraints: no logos, no text, no watermark

Edit example (invariants)

Use case: precise-object-edit
Asset type: product photo background replacement
Primary request: replace only the background with a warm sunset gradient
Constraints: change only the background; keep the product and its edges unchanged; no text; no watermark

Prompting best practices

• Structure prompt as scene/backdrop -> subject -> details -> constraints.
• Include intended use (ad, UI mock, infographic) to set the mode and polish level.
• Use camera/composition language for photorealism.
• Only use SVG/vector stand-ins when the user explicitly asked for vector output or a non-image placeholder.
• Quote exact text and specify typography + placement.
• For tricky words, spell them letter-by-letter and require verbatim rendering.
• For multi-image inputs, reference images by index and describe how they should be used.
• For edits, repeat invariants every iteration to reduce drift.
• Iterate with single-change follow-ups.
• If the prompt is generic, add only the extra detail that will materially help.
• If the prompt is already detailed, normalize it instead of expanding it.
• For Codex API direct controls, see references/codex-direct.md. For CLI fallback only, see references/cli.md and references/image-api.md for API-key-backed behavior.
• For transparent images, use the built-in-first chroma-key workflow unless the request explicitly needs native transparency. Native transparency requires either an explicit supported direct --image-model plus --background transparent, or confirmation before switching to CLI gpt-image-1.5.

More principles shared by both modes: references/prompting.md. Copy/paste specs shared by both modes: references/sample-prompts.md.

Guidance by asset type

Asset-type templates (website assets, game assets, wireframes, logo) are consolidated in references/sample-prompts.md.

Codex API direct image options

The Codex direct CLI passes advanced options to the hosted Responses image_generation tool by default without requiring OPENAI_API_KEY. Use --transport image-api to use the Codex Image API generation/edit route instead.

• Use --quality low for drafts and quick iterations; use --quality high or --quality auto for final assets, dense text, diagrams, identity-sensitive edits, and high-resolution outputs.
• Use --size auto or explicit sizes such as 1024x1024, 1536x1024, 1024x1536, 2048x1152, or 3840x2160 when the selected image model supports them.
• Use --output-format png|webp|jpeg; use --output-compression 0..100 only with webp or jpeg.
• Use --reference repeatedly for local inputs. For an edit target plus mask, pass the edit target as the first --reference and the mask through --mask.
• Use --partial-images 1..3 only when streamed previews are useful; never treat a partial image preview as the completed image, even if it looks usable. Final project output still comes from the completed image. If the last partial is byte-identical to the completed image, the CLI renames that partial to the final output path.
• Use --timeout <seconds> to override the default 600-second network request timeout across Responses and Image API transports.
• Use --reasoning-effort <value> only when the Responses request should explicitly set reasoning.effort; omit it to let the selected model and server defaults apply. The default Responses model gpt-5.5 supports none, low, medium (default), high, and xhigh; other models can differ, and additional values may become available, so the CLI does not restrict the value. Check each model page and https://developers.openai.com/api/docs/guides/reasoning when selecting an effort.
• Use --hide-response-details when failure output may be fed back into a model context; redacted log files still keep response details for inspection.
• Use --verbose only when debug details are useful.
• Logs are written next to the generated original as append-only records, begin with start metadata for the invocation, ordered reference and mask paths, and request, and timestamp each event as log metadata. CLI info, debug, and error messages are appended as separate events. Responses logs are redacted event logs; Image API logs are redacted JSONL event logs.
• --model selects the model for the active transport. --image-model overrides --model for Image API calls and maps to the tool-level model field for --transport responses. --background transparent requires a transparency-capable image model and a transparent-capable output format.

gpt-image-2 guidance for CLI fallback

The fallback CLI defaults to gpt-image-2.

• Use gpt-image-2 for new CLI/API workflows unless the request needs true model-native transparent output.
• If a transparent request may need CLI fallback, ask before using gpt-image-1.5 unless the user already explicitly requested gpt-image-1.5, scripts/image_gen.py, or CLI fallback. Explain that the built-in chroma-key path is the default, but true transparency requires gpt-image-1.5 because gpt-image-2 does not support background=transparent.
• gpt-image-2 always uses high fidelity for image inputs; do not set input_fidelity with this model.
• gpt-image-2 supports quality values low, medium, high, and auto.
• Use quality low for fast drafts, thumbnails, and quick iterations. Use medium, high, or auto for final assets, dense text, diagrams, identity-sensitive edits, or high-resolution outputs.
• Square images are typically fastest to generate. Use 1024x1024 for fast square drafts.
• If the user asks for 4K-style output, use 3840x2160 for landscape or 2160x3840 for portrait.
• gpt-image-2 size may be auto or WIDTHxHEIGHT if all constraints hold: max edge <= 3840px, both edges multiples of 16px, long-to-short ratio <= 3:1, total pixels between 655,360 and 8,294,400.

Popular gpt-image-2 sizes:

• 1024x1024 square
• 1536x1024 landscape
• 1024x1536 portrait
• 2048x2048 2K square
• 2048x1152 2K landscape
• 3840x2160 4K landscape
• 2160x3840 4K portrait
• auto

Fallback CLI mode only

Temp and output conventions

These conventions apply only to the CLI fallback. They do not describe built-in image_gen output behavior.

• Use tmp/imagegen/ for intermediate files (for example JSONL batches); delete them when done.
• Write final artifacts under output/imagegen/.
• Use --out or --out-dir to control output paths; keep filenames stable and descriptive.

Dependencies

Use only the skill-local virtual environment at $CODEX_HOME/skills/codex-imagegen-free-reference/.venv.

Create it if needed:

SKILL_ROOT="${CODEX_HOME:-$HOME/.codex}/skills/codex-imagegen-free-reference"
uv venv "$SKILL_ROOT/.venv"

Required Python package:

uv pip install --python "$SKILL_ROOT/.venv/bin/python" openai

Required for local chroma-key removal and optional downscaling:

uv pip install --python "$SKILL_ROOT/.venv/bin/python" pillow

Portability note:

• If you are using the installed skill outside this repo, still create and use .venv inside that installed skill directory.
• On Windows, pass $env:CODEX_HOME\skills\codex-imagegen-free-reference\.venv\Scripts\python.exe to uv pip install --python.

Environment

• OPENAI_API_KEY must be set for live API calls.
• Do not ask the user for OPENAI_API_KEY when using the built-in image_gen tool.
• Never ask the user to paste the full key in chat. Ask them to set it locally and confirm when ready.

If the key is missing, give the user these steps:

1. Create an API key in the OpenAI platform UI: https://platform.openai.com/api-keys
2. Set OPENAI_API_KEY as an environment variable in their system.
3. Offer to guide them through setting the environment variable for their OS/shell if needed.

If installation is not possible in this environment, tell the user which dependency is missing and how to install it into their active environment.

Script-mode notes

• CLI commands + examples: references/cli.md
• API parameter quick reference: references/image-api.md
• Network approvals / sandbox settings for CLI mode: references/codex-network.md

Reference map

• references/prompting.md: shared prompting principles for both modes.
• references/sample-prompts.md: shared copy/paste prompt recipes for both modes.
• references/cli.md: fallback-only CLI usage via scripts/image_gen.py.
• references/codex-direct.md: Codex-auth direct CLI usage and advanced image-generation tool options.
• references/image-api.md: fallback-only API/CLI parameter reference.
• references/codex-network.md: fallback-only network/sandbox troubleshooting for CLI mode.
• scripts/image_gen.py: fallback-only CLI implementation. Do not load or use it unless the user explicitly chooses CLI mode or explicitly confirms a transparent request's true CLI transparency fallback.
• $CODEX_HOME/skills/codex-imagegen-free-reference/scripts/remove_chroma_key.py: local post-processing helper for built-in transparent-image requests.