Bug: Regression: `image_url` validation fails for local file URIs (`file://` protocol) in v1.0.0

[dmeehan1968]

Describe the bug
In version 1.0.0, passing a local file URI (e.g., file:///path/to/file.png) to the image_url field results in a 400 Bad Request validation error. Previously, local file URIs did not trigger this validation failure.

To Reproduce
Send a payload to the ACP containing a local file URI in the image_url parameter:

{
        "type": "image",
        "mimeType": "image/png",
        "data": "[redacted image/png payload as base64]",
        "uri": "file:///Users/dmeehan/Desktop/Screenshot.png"
 }

Expected behavior
The local file URI should either be accepted and resolved correctly, or ignored if inline data is provided. It should not fail schema validation with a 400 error. It should also handle escaped URI's - e.g. %20 for spaces.

Actual behavior
The API returns a 400 Bad Request response:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "invalid_value",
    "message": "Invalid 'input[0].content[0].image_url'. Expected a valid URL, but got a value with an invalid format.",
    "param": "input[0].content[0].image_url"
  },
  "status": 400
}

Environment:

• OS: macOS
• AgentClientProtocol Codex ACP Version: 1.0.0

Additional Context

• In previous versions of Codex ACP, combining data (base64) along with a file:// URI succeeded. It is possible the uri property was previously ignored when data was present, and v1.0.0 introduced stricter validation that now rejects the file protocol.
• A temporary workaround is to completely omit the file URI and only send the base64 data property.

[dmeehan1968]

@benbrandt I see you're dealing with this, but I did a bit of research and it seems that @openai/codex only supports data: uri's.

Your change looks like it will restore the prior functionality but will allow unsupported uri's through (which might be the most reasonable way to handle it.

---

Inspected the installed @openai/codex@0.142.0 package. It installs a native Rust binary, so I mapped it to the exact upstream tag rust-v0.142.0 (3a76f3a...) and checked those sources.

The error text itself is generated by the OpenAI Responses API, not by this repo. This repo/Codex generates the request field that OpenAI rejects:

1. src/CodexAcpClient.ts maps ACP image blocks:

   const url = block.uri ?? `data:${block.mimeType};base64,${block.data}`;
   return {type: "image", url};

   So if block.uri exists, it is preferred even when block.data is available.

2. src/CodexAcpClient.ts sends that to Codex app-server as turn/start.

3. In Codex rust-v0.142.0, app-server maps that v2 input into core input with V2UserInput::into_core:
   https://github.com/openai/codex/blob/3a76f3ac68c8949d1cac6ea769b6ec7b8953a415/codex-rs/app-server/src/request_processors/turn_processor.rs#L430-L435

4. Core protocol converts UserInput::Image { image_url } into Responses content:
   https://github.com/openai/codex/blob/3a76f3ac68c8949d1cac6ea769b6ec7b8953a415/codex-rs/protocol/src/models.rs#L1723-L1731

5. The OpenAI request field is defined as ContentItem::InputImage { image_url }:
   https://github.com/openai/codex/blob/3a76f3ac68c8949d1cac6ea769b6ec7b8953a415/codex-rs/protocol/src/models.rs#L842-L853

6. The final Responses request is built with that input unchanged:
   https://github.com/openai/codex/blob/3a76f3ac68c8949d1cac6ea769b6ec7b8953a415/codex-rs/core/src/client.rs#L771-L817

Key finding: in @openai/codex@0.142.0, image preparation only processes data: URLs and does not validate or rewrite other image strings before the Responses request:
https://github.com/openai/codex/blob/3a76f3ac68c8949d1cac6ea769b6ec7b8953a415/codex-rs/core/src/image_preparation.rs#L72-L117

So the most likely local source is buildPromptItems() preferring block.uri. If ACP sends an image with a URI like a local path, file://..., or another non-Responses-compatible URI while also including base64 data, this adapter forwards the URI, Codex turns it into image_url, and OpenAI rejects it as input[2].content[2].image_url.

Side effect: bun install created an untracked bun.lock. No source files were edited.

[benbrandt]

Looks like the responses endpoint handles external urls: https://developers.openai.com/api/reference/resources/responses/methods/create#(resource)%20responses%20%3E%20(model)%20response_input_image%20%3E%20(schema)%20%3E%20(property)%20image_url

So I think my fix should work here

[dmeehan1968]

@benbrandt That also suggests that file:// should have worked as it doesn't qualify which urls are acceptable, however perhaps that's out of scope here. The issues seems to have been that uri was taking precedence over data when it had previously been the other way around.

[benbrandt]

yeah I guess in the openai docs they give references for remote images (http(s)) and data, so I think that is the problem