Windows and WSL Codex CLI sessions report built-in `image_gen` tool unavailable even when `image_generation = true` and Azure image generation works directly
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
- Ensure
image_generation = trueis enabled in~/.codex/config.toml. - Export a valid Azure key and endpoint for the image-capable Azure resource.
- 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."
- Codex enters the image workflow, reads the
imagegenskill, and then exits with the missing-tool error above.
Reproduction B: native Windows
- Ensure
image_generation = trueis enabled in%USERPROFILE%\.codex\config.toml. - Run native Windows Codex CLI.
- 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.
- 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.
- 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/croot 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.pngwas a valid PNG written to the workspace.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗