Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
When a Codex-native run already contains inbound images and the selected model supports vision, the turn can still expose the dynamic image tool. In that situation the model may call image again instead of answering from the already-provided image input, and the run can stall with no reply delivered.
I also found a related image fallback mismatch: bare image-model overrides (for example gpt-5.4-mini) currently inherit DEFAULT_PROVIDER instead of the provider configured in agents.defaults.imageModel.primary. If the configured image model lives under openai-codex/..., a bare override can resolve back to plain openai/....
Steps to reproduce
- Configure OpenClaw to use a Codex-native harness with a vision-capable Codex model.
- Send a message with an image attachment through any channel that forwards the image into the embedded run.
- Observe that the turn input already contains the inbound image.
- Observe that the dynamic tool catalog still exposes
image.
- When the model emits an
image tool call, the run can stall instead of replying.
Expected behavior
A Codex-native vision turn that already has inbound image input should answer directly from that input and should not re-expose the dynamic image tool for the same turn. Bare image-model overrides should also inherit the configured image-model provider.
Actual behavior
The run can remain stuck after emitting a dynamic image tool call, so channels show typing and then silence. Separately, image-model overrides such as gpt-5.4-mini can resolve under the wrong provider when agents.defaults.imageModel.primary is configured under openai-codex/....
OpenClaw version
2026.4.10 (reproduced), current main still contains the same code paths
Operating system
macOS 15.x
Install method
npm global
Model
codex/gpt-5.4
Provider / routing chain
openclaw -> codex app-server
Additional provider/model setup details
No private config is required to reproduce this. The key condition is: a vision-capable Codex model, inbound images already present in the turn input, and the dynamic tool catalog still exposing image.
Logs, screenshots, and evidence
Impact and severity
Affected: Codex-native image turns across channels
Severity: High (stalls image replies)
Frequency: Reproduced consistently under the conditions above
Consequence: the run can hang until the channel typing TTL expires
Additional information
Observed on 2026.4.10. I also checked the current source and the same behavior still exists in extensions/codex/src/app-server/run-attempt.ts and src/agents/model-fallback.ts. A local patch that filters image when vision input is already present, and that inherits the configured image-model provider for bare overrides, resolves the issue.
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
When a Codex-native run already contains inbound images and the selected model supports vision, the turn can still expose the dynamic
imagetool. In that situation the model may callimageagain instead of answering from the already-provided image input, and the run can stall with no reply delivered.I also found a related image fallback mismatch: bare image-model overrides (for example
gpt-5.4-mini) currently inheritDEFAULT_PROVIDERinstead of the provider configured inagents.defaults.imageModel.primary. If the configured image model lives underopenai-codex/..., a bare override can resolve back to plainopenai/....Steps to reproduce
image.imagetool call, the run can stall instead of replying.Expected behavior
A Codex-native vision turn that already has inbound image input should answer directly from that input and should not re-expose the dynamic
imagetool for the same turn. Bare image-model overrides should also inherit the configured image-model provider.Actual behavior
The run can remain stuck after emitting a dynamic
imagetool call, so channels show typing and then silence. Separately, image-model overrides such asgpt-5.4-minican resolve under the wrong provider whenagents.defaults.imageModel.primaryis configured underopenai-codex/....OpenClaw version
2026.4.10 (reproduced), current main still contains the same code paths
Operating system
macOS 15.x
Install method
npm global
Model
codex/gpt-5.4
Provider / routing chain
openclaw -> codex app-server
Additional provider/model setup details
No private config is required to reproduce this. The key condition is: a vision-capable Codex model, inbound images already present in the turn input, and the dynamic tool catalog still exposing
image.Logs, screenshots, and evidence
Impact and severity
Affected: Codex-native image turns across channels
Severity: High (stalls image replies)
Frequency: Reproduced consistently under the conditions above
Consequence: the run can hang until the channel typing TTL expires
Additional information
Observed on 2026.4.10. I also checked the current source and the same behavior still exists in
extensions/codex/src/app-server/run-attempt.tsandsrc/agents/model-fallback.ts. A local patch that filtersimagewhen vision input is already present, and that inherits the configured image-model provider for bare overrides, resolves the issue.