[Remote][macOS] Image generation succeeds locally but media result is blocked by security-hook validation
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT/Codex Desktop 26.803.61601 (build 6396)
Bundled Codex CLI: 0.147.0-alpha.6.5
What subscription do you have?
Paid ChatGPT subscription (exact tier omitted from this public report)
What platform is your computer?
- macOS
26.5.2(build25F84) - Apple Silicon /
arm64 - The affected turn was started or steered through Remote in the ChatGPT mobile app, with the work running on the connected Mac.
What issue are you seeing?
Built-in image generation completes and writes a PNG locally, but the tool result is reported as failed because an output security hook cannot validate it.
The localized error shown after the tool call is:
보안 훅이 입력을 안전하게 검증하지 못해 작업을 중단했습니다. 실제 입력값은 표시하지 않습니다.
Approximate English meaning:
The task was stopped because the security hook could not safely validate the input. The actual input is not displayed.
This reproduced with:
- a long UI concept prompt plus local reference images;
- a shorter UI concept prompt plus references;
- the same kind of prompt using recent conversation images instead of file paths;
- a short prompt without references;
- a minimal benign prompt:
Create a plain orange circle centered on a white square background. No text.
All five calls were surfaced as failures. However, each call created a new PNG under $CODEX_HOME/generated_images/<thread-id>/exec-*.png. The files were created at the corresponding call times and were non-empty (roughly 0.85–1.49 MB).
Calling the built-in local image viewer on one of those generated PNGs from the same Remote-started turn also fails immediately with the same security-hook message. This suggests image generation itself succeeds and the failure occurs while validating or returning media tool output to the conversation.
No newly generated image is rendered in the mobile chat despite the local file being present.
What steps can reproduce the bug?
- Connect the ChatGPT mobile app to a Mac through Remote.
- Start or continue a Codex task from the mobile app.
- Have the agent invoke built-in image generation with this minimal prompt:
Create a plain orange circle centered on a white square background. No text.
- Wait for the image-generation tool call.
- Observe that the tool reports the localized security-hook validation failure.
- On the connected Mac, inspect
$CODEX_HOME/generated_images. - Observe that a new non-empty PNG was nevertheless created at the time of the failed call.
- Ask the agent to inspect that PNG with the local image viewer in the same turn.
- Observe the same security-hook validation failure.
The issue did not change when references, prompt length, personal names, metrics, and project-specific content were removed.
A desktop-origin control turn has not yet been run, so the evidence establishes the Remote-started failure but does not yet prove that desktop-origin turns are unaffected.
What is the expected behavior?
When image generation succeeds and a PNG is written locally:
- the generated image should be returned and rendered in the originating mobile Remote conversation;
- the tool should report success;
- local image inspection should be able to return the image;
- if output validation fails, the error should distinguish a post-generation/output-delivery failure from an unsafe input rejection and provide a request/session identifier for support.
Additional information
The strongest current inference is a Remote/media output validation or handoff bug, not a prompt-policy rejection:
- the minimal orange-circle prompt fails;
- the generator produces a valid non-empty file;
- the failure occurs when returning both generated and locally viewed image output;
- text and shell tools in the same Remote task continue to work.
Potentially related but not identical:
- #35371: Remote on iOS drops tool images from completed turns.
- #36814 and #21167: Desktop conversation event desynchronization / unknown-conversation symptoms.
Privacy: no raw logs, usernames, local paths, conversation IDs, prompts containing business content, or generated images are attached. A private feedback session and redacted log excerpt can be provided if maintainers request them.
2 Comments
Correction after deeper local investigation: image generation itself succeeds, and this is not currently evidence of an OpenAI Remote or image-generation defect.
The affected machine has a custom local
PostToolUsesecret-guard hook. Generated image results contain roughly 0.9–1.5 MB base64 media bodies, while that guard treats every JSON string as scannable text and fails closed after a 512 KiB scanning budget. The same hook also blocksview_image, which explains why both generated and existing images appeared to fail.I have prepared a local fix that replaces only image/audio/video payload bodies with an opaque placeholder in the guard's scanning view while continuing to inspect surrounding text and metadata. Its regression suite passes 173 checks, including generated-image data URLs and MCP image content blocks.
I will keep the issue open only until the patched guard is activated and the mobile-origin workflow is verified end to end. If that passes, I will close this as a local configuration issue. Apologies for the premature product-level report.
Closing after end-to-end verification. The root cause was my local custom PostToolUse guard scanning the full encoded image payload and failing closed on its size. Replacing that legacy guard with the Rust Meerkat Guard, which treats image/audio/video bodies as opaque while still scanning surrounding metadata and text, restored both existing-image tool output and fresh image-generation output. This is not an upstream Codex defect.