Windows Desktop: view_image cannot read an authorized workspace image when split writable roots trigger unelevated sandbox refusal

Summary

On Codex Desktop for Windows, the built-in view_image tool cannot open a PNG that exists inside the authorized project workspace. The tool fails while preparing its filesystem sandbox, before it reads or decodes the image.

The same workspace file can be discovered through ordinary read-only workspace commands. The failure is specific to the view_image execution path when the managed permission profile contains multiple writable roots.

Environment

• Codex Desktop: 26.707.8479.0
• Bundled Codex CLI: 0.137.0
• OS: Microsoft Windows NT 10.0.26200.0 x64
• Shell: Windows PowerShell 5.1.26100.8737
• Permission mode: managed workspace profile / restricted filesystem
• Writable-root shape:
• <workspace>
• <codex-visualization-workspace>
• Image location: an existing PNG beneath <workspace>

Local usernames, account details, exact paths, workspace identifiers, and image contents are intentionally omitted from the public report.

Steps to reproduce

1. Open a local project in Codex Desktop on native Windows.
2. Use a managed workspace permission profile that supplies both the project workspace and a Codex visualization workspace as writable roots.
3. Place or identify a valid PNG beneath the project workspace.
4. Confirm that the file is visible through a read-only workspace file listing.
5. Ask Codex to inspect that PNG with the built-in view_image tool, passing its absolute path.

Actual behavior

view_image fails before the file is read:

unable to locate image at `<workspace>\path\image.png`:
failed to prepare fs sandbox: failed to prepare windows sandbox wrapper:
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly; refusing to run unsandboxed

The failure reproduced on both attempts in the same Desktop task.

Expected behavior

view_image should be able to perform a read-only operation on an image located inside an authorized workspace root, including when the managed profile contains multiple writable roots.

If the unelevated Windows sandbox cannot represent that policy, the tool should either:

1. use a read-only broker that can safely access the authorized file;
2. use a supported sandbox path that preserves the supplied root policy; or
3. expose a narrow approval path for this specific read operation.

It should not misreport a sandbox-construction failure as an inability to locate the image.

Impact

This blocks reference-based image workflows in Codex Desktop on Windows:

• Screenshots cannot be inspected before image editing.
• Generated or checked-in visual assets cannot be validated with the built-in viewer.
• Image editing cannot preserve the source because the image cannot be attached to the model.
• The agent is forced to generate a replacement from text and CSS descriptions, producing a materially lower-fidelity result.
• The user has no approval control available to recover the read-only operation.

This is a harness/tooling failure, not a model-quality problem or image-generation-service failure.

Diagnostic boundary

• The PNG exists beneath the authorized project workspace.
• Read-only shell tooling can enumerate the file.
• view_image fails during filesystem-sandbox preparation, before image decoding.
• The error explicitly identifies the unelevated restricted-token sandbox and split writable roots.
• Generating a new image without ingesting the local PNG succeeds, so the failure is in local-image access rather than generation.

Possibly related

• Restricted-token sandbox and writable-root SID handling: https://github.com/openai/codex/issues/22044
• Sandbox initialization failure affecting read-only commands: https://github.com/openai/codex/issues/10601
• Windows Desktop workspace-write / ACL setup instability: https://github.com/openai/codex/issues/19238
• Existing view_image workflow friction: https://github.com/openai/codex/issues/12439
• Recent view_image selected-environment filesystem routing: https://github.com/openai/codex/pull/29526

PR #29526 is included because it routes view_image reads through the selected environment's filesystem and sandbox context. This report does not claim that the PR caused the failure.