Windows VS Code `view_image` intermittently rejects a local NTFS PNG after original-detail payload construction

Summary

On Windows in the VS Code Codex extension, native view_image(detail=original) can intermittently fail after sandbox preparation, local file access, and original-detail payload construction, with the conversation reporting:

image content omitted because it could not be processed

The same runtime, same extension build, same local NTFS workspace, same image bytes, and same detail=original later succeeded in the same IDE conversation.

This appears distinct from earlier Windows failures that stop before payload creation, such as:

• elevated UNC/ACL setup failures
• unelevated split writable-root refusals

Environment

• OS: Windows x64
• Surface: VS Code Codex extension
• Extension version: 26.727.40816
• IDE-serving Codex runtime: 0.146.0-alpha.9.2
• Windows sandbox mode: elevated
• Workspace: fixed local NTFS directory
• No UNC, mapped drive, or remote repository root involved in this reproduction

Input

• A valid local PNG
• Dimensions: 1024x1536
• Pixel format: 24-bit RGB
• Independently decodes successfully outside the native tool path

Reproduction

1. Open a local NTFS workspace in the VS Code Codex extension.
2. Invoke built-in view_image on a valid local PNG with detail=original.

Observed failing behavior

1. Sandbox preparation succeeds.
2. Local filesystem lookup succeeds.
3. An original-detail image payload is produced.
4. The conversation then reports:

image content omitted because it could not be processed

1. Model vision receives no usable image.

Intermittency control

In the same IDE conversation, with the same serving process, same runtime executable, same extension build, same elevated sandbox mode, same local workspace, same image bytes, and same detail=original, a later identical invocation succeeded and delivered usable full-image vision.

No CLI override or local configuration change was present.

Expected

A valid local PNG should either:

1. consistently reach model vision, or
2. fail with a more specific diagnostic identifying the rejected image property or downstream processing stage.

Distinction from other Windows issues

This failure occurs after:

• sandbox preparation,
• local file access,
• and original-detail payload construction.

That makes it observably different from:

• Windows elevated UNC ACL setup failures
• Windows unelevated split writable-root refusals

Those fail earlier, before image attachment reaches downstream preparation.

Possibly related

Issue #30121 may be adjacent because it appears to touch centralized image preparation / deferred image handling, but I’m not claiming a common root cause.

Notes

• No private machine names, repository names, filenames, or workspace paths are included here.
• No configuration, runtime, image, repository, or installation state was intentionally changed between the failing and succeeding invocations.