[macOS App] view_image and image_gen local reference reads fail when fs sandbox helper is SIGKILLed

[macOS App] view_image and image_gen local reference reads fail because fs sandbox helper is SIGKILLed

What version of the Codex App are you using?

Codex App 26.727.40816 (bundle 6067). The desktop log reports Codex app-server 0.146.0-alpha.9.2.

What subscription do you have?

ChatGPT account in Codex Desktop. Exact tier is not relevant to this local filesystem sandbox failure.

What platform is your computer?

Darwin 25.5.0 arm64 arm
macOS 26.5.2 (25F84)

What issue are you seeing?

In Codex Desktop on macOS, every local-image read through the tool filesystem sandbox fails because the filesystem sandbox helper is immediately terminated with SIGKILL.

The failure blocks both:

• view_image inspection of local images;
• image_gen calls that use referenced_image_paths for image-to-image generation.

Representative errors:

unable to locate image at `<workspace>/reference.png`:
fs sandbox helper failed with status signal: 9 (SIGKILL)

unable to read referenced image at `<workspace>/reference.png`:
fs sandbox helper failed with status signal: 9 (SIGKILL)

This is not limited to a workspace path. The exact same error occurs for images in all of these locations:

1. an authorized workspace root;
2. a versioned copy inside the workspace;
3. the Codex visualizations writable root;
4. $CODEX_HOME/generated_images, containing output created by the built-in image generator;
5. $CODEX_HOME/attachments, containing an attachment created by Codex itself;
6. /private/tmp.

The same files are readable and decodable with file, sips, Pillow, FFmpeg, and nodeRepl.emitImage(file://...).

The impact is severe for iterative image/video workflows: a generated asset can be saved, but it cannot be fed back to image_gen as the next iteration's identity/style reference. The workflow is forced to ask the user to upload the same image again as a chat attachment.

What steps can reproduce the bug?

1. Open a local project in Codex Desktop on macOS using a managed workspace-write permission profile.
2. Put a valid RGB PNG under the authorized workspace root.
3. Confirm the file exists and is decodable using ordinary local tooling.
4. Call view_image with the PNG's absolute path.
5. Observe the filesystem helper SIGKILL error.
6. Call built-in image_gen with the same path in referenced_image_paths.
7. Observe the same helper SIGKILL before generation starts.

The failure was reproduced with:

• RGB PNG, 1024 × 1536, approximately 2.4 MB;
• normalized JPEG, 512 × 768, approximately 97 KB;
• cp -X copies;
• permissions 0600 and 0644;
• copies in each location listed above.

Restarting the desktop application and confirming that it was on the latest available client did not resolve the problem.

What is the expected behavior?

view_image and image_gen.referenced_image_paths should be able to read valid images inside authorized roots, including images created by Codex itself under generated_images and attachments.

If sandbox setup fails, the error should identify the sandbox construction failure rather than reporting that the image cannot be located. A read-only image broker should not terminate with SIGKILL for every allowed local path.

Additional information

The macOS com.apple.provenance extended attribute was investigated. cp -X, format conversion, permission changes, and attempts to clear the attribute did not alter the behavior. Because Codex-owned generated image and attachment paths fail identically, this does not appear to be a single-file quarantine or encoding issue.

No image content, user name, absolute home path, thread ID, authentication material, or private project information is included in this report.

Possibly related, but not duplicates:

• #30121 — local reference images fail after environment-backed reads were introduced; reported primarily on Windows.
• #32839 — Windows Desktop view_image failure with split writable roots.
• #24407 — intermittent apply_patch/file-change failure; in this macOS session some updates to existing files also failed through the same filesystem helper, while adding new versioned files succeeded.

The most relevant code paths appear to be:

• codex-rs/core/src/tools/handlers/view_image.rs
• codex-rs/ext/image-generation/src/tool.rs
• environment filesystem reads using file_system_sandbox_context

Request: please add a macOS regression test covering view_image and image_gen.referenced_image_paths for workspace, generated-image, and attachment roots, and preserve the helper's stderr/termination reason when sandbox setup fails.