›_ Codex Issues
Codex Issues / #19133

Windows and WSL Codex CLI sessions report built-in `image_gen` tool unavailable even when `image_generation = true` and Azure image generation works directly

Open 💬 4 comments Opened Apr 23, 2026 by powyncify

What version of Codex CLI is running?

0.122.0 on WSL / Linux shell ; 0.120.0 on native Windows; persists on 0.123.0

What subscription do you have?

Azure OpenAI

Which model were you using?

gpt-5.4

What platform is your computer?

Native Windows = Microsoft Windows NT 10.0.26200.0 x64; WSL = Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

WSL = GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu); Windows = PowerShell / cmd-launched Codex CLI

What issue are you seeing?

In both WSL and native Windows Codex CLI sessions, image-generation requests from codex exec fail because the built-in image_gen tool is not available in the session, even though image_generation = true is enabled in config.

WSL observed message:

Generation failed. Exact error: built-in `image_gen` tool is not available in this session, so I could not generate or save `wolf-study-wsl.png`.

Native Windows observed message:

The built-in image tool path described by the skill is not exposed in this session

On Windows, Codex then completed the turn by scripting PowerShell to create a deterministic placeholder PNG instead of using the built-in image-generation pipeline.

Direct Azure image generation works outside Codex from both Windows and WSL command lines, so this does not appear to be an Azure deployment problem.

What steps can reproduce the bug?

Reproduction A: WSL

  1. Ensure image_generation = true is enabled in ~/.codex/config.toml.
  2. Export a valid Azure key and endpoint for the image-capable Azure resource.
  3. Run:
export AZURE_OPENAI_API_KEY='[redacted]'
export AZURE_OPENAI_ENDPOINT='https://<image-resource>.openai.azure.com/'

codex exec --enable image_generation --full-auto --skip-git-repo-check \
  -c 'model_providers.azure.base_url="https://<image-resource>.openai.azure.com/openai/v1"' \
  -C "/mnt/c/<redacted-user>/Documents/<redacted-path>" \
  "Generate an image from this prompt and save the final image as wolf-study-wsl.png in the current directory: A cozy study with a grey wolf sitting at a wooden desk using a laptop, a coffee mug nearby, bookshelves in the background, soft morning light, highly detailed, realistic photo. If generation fails, report the exact error."
  1. Codex enters the image workflow, reads the imagegen skill, and then exits with the missing-tool error above.

Reproduction B: native Windows

  1. Ensure image_generation = true is enabled in %USERPROFILE%\.codex\config.toml.
  2. Run native Windows Codex CLI.
  3. Use a minimal prompt such as:
Generate an image from this prompt and save the final image as windows-image-probe.png in the current directory: A simple red square on a white background. If generation fails, report the exact error.
  1. Codex enters the image workflow, loads the local image-generation skill, and then reports that the built-in image tool path is not exposed in the session.
  2. Instead of generating with image_gen, Codex scripts PowerShell to create a local PNG file.

What is the expected behavior?

If image_generation = true is enabled and the session otherwise supports Codex image generation, Codex should expose the built-in image_gen tool and complete the image-generation request.

If a given session or provider truly does not support built-in image generation, Codex should fail early with a clear capability error rather than entering the image workflow and then discovering that the tool is unavailable.

Additional information

Relevant sanitized config excerpt:

model_provider = "azure"
model = "gpt-5.4"

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://<text-resource>.openai.azure.com/openai/v1"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"

[features]
image_generation = true
memories = true

Additional observations:

  • Earlier WSL failures from /mnt/c root were sandbox/workdir problems:
bwrap: Can't create file at /mnt/c/.codex: Permission denied

That specific issue was resolved by running from a deeper writable directory. The remaining failure was still the missing built-in image tool.

  • Direct Azure image generation works outside Codex. For example, a direct request to:
https://<image-resource>.openai.azure.com/openai/deployments/<image-deployment>/images/generations?api-version=2024-02-01

can generate a PNG successfully when the correct Azure key is supplied.

  • On native Windows, Codex still completed the turn, but only by generating a deterministic replacement file instead of using built-in image generation. The resulting windows-image-probe.png was a valid PNG written to the workspace.

View original on GitHub ↗

4 Comments

powyncify · 4 months ago

Tested again after upgrading to codex-cli 0.123.0. The issue does not appear to be resolved, so this issue should remain open.

Native Windows (0.123.0)

Reproduction:

  • codex exec --enable image_generation --full-auto --skip-git-repo-check ...
  • Prompt: generate a simple PNG in the current directory

Observed behavior:

  • Codex entered the image workflow.
  • It read the local imagegen skill.
  • It then reported:
The built-in image generation tool isn’t exposed in this session
  • Instead of generating through the built-in image pipeline, it created a deterministic raster PNG in PowerShell.

WSL (0.123.0)

I tested two cases.

  1. Very simple geometric prompt:
  • Codex chose a deterministic local bitmap path rather than AI image generation.
  1. Real image-generation prompt:
  • Prompt: A cozy study with a red fox sitting at a wooden desk using a laptop, a coffee mug nearby, bookshelves in the background, soft morning light, highly detailed, realistic photo.
  • Codex entered the image workflow, checked the imagegen skill, and then reported:
Built-in path: `image_gen` tool is unavailable in this session.

It also reported that the explicit CLI fallback could not be used in that session because OPENAI_API_KEY was not set and network access was restricted there.

Conclusion

As of 0.123.0, the built-in image_gen tool still does not appear to be exposed in the tested Codex CLI sessions:

  • native Windows CLI: still affected
  • WSL CLI: still affected

Direct Azure image generation outside Codex continues to work, so the problem still looks specific to Codex CLI session/tool exposure rather than the underlying image model or Azure deployment.

yrasool · 3 months ago

I’m seeing the same core failure in Codex desktop/app: Codex can load the $imagegen skill, but the actual built-in image_gen tool is not exposed/callable in the session. Image-generation workflows start normally, then dead-end when they need the tool.

wei1260 · 1 month ago

最近5.6sol中也出现了生成不了图的情况

bleraynari · 29 days ago

Codex CLI 0.146.0 reproduction: image_gen is not exposed

Summary

Codex CLI discovers and reads the bundled imagegen skill, but the built-in
image_gen tool is not exposed to the session. The agent therefore cannot make
an image-generation call.

This was reproduced outside the project in an empty temporary directory, so
project-local skills and workspace files are not part of the minimal
reproduction.

Environment

| Field | Value |
| --- | --- |
| Codex CLI | 0.146.0 |
| OS | Windows (PowerShell) |
| Provider | openai |
| Model | gpt-5.6-terra |
| Work directory | %TEMP%\codex-imagegen-probe (empty directory) |
| Sandbox reported by the probe | read-only |
| Approval policy | never |

No custom model provider, Azure configuration, Bedrock configuration, or API
fallback was requested for this reproduction.

Minimal reproduction

$probe = Join-Path $env:TEMP 'codex-imagegen-probe'
New-Item -ItemType Directory -Force $probe | Out-Null

codex exec --enable image_generation --skip-git-repo-check -C $probe `
  "This is an isolated image-tool availability test. Use the built-in image_gen tool to create a simple shaded red 3D isometric cube. Do not read project skills, ask questions, write files other than the generated image, make a plan, or create documentation."

Actual result

The CLI first read the bundled skill at:

C:\Users\user\.codex\skills\.system\imagegen\SKILL.md

It then returned:

The built-in `image_gen` tool is unavailable in this session, so I couldn’t generate the cube.

No image was generated and no API fallback was attempted.

Expected result

With the OpenAI provider and --enable image_generation, Codex CLI should
expose the built-in image_gen tool and generate the requested image, or
report a documented eligibility/feature-gate reason before loading the image
generation workflow.

Scope and notes

  • A first attempt within C:\mecha was not used as the primary reproduction

because that repository's local brainstorming skill required a design
approval before image generation could begin.

  • The isolated reproduction removes that project-level variable.
  • The reported failure is tool absence, not a file-write, authentication, rate

limit, or image-generation API error.

  • The probe reported a read-only sandbox. If image generation is intentionally

unavailable in that sandbox mode, please document the requirement or return a
specific diagnostic instead of reporting the tool as unavailable.

  • A PowerShell profile warning about constrained-language dot-sourcing appeared

after the skill was read. It did not replace or explain the final
image_gen-unavailable message, but a full terminal transcript can be
provided privately if useful.

Request

Please confirm whether built-in image generation is currently supported for
Codex CLI 0.146.0 on Windows when using the standard OpenAI provider. If it is
supported, please identify the required feature flag, authentication state, or
sandbox mode that causes the hosted tool to be included in the session.

Related public reports