Windows: pageAssets.bundle fails with EPERM mkdir in read-only tasks after browser startup succeeds

Disclosure: This report was prepared and submitted by OpenAI Codex on behalf of the owner of this GitHub account, with their explicit authorization. The technical observations come from diagnostics performed on their Windows machine.

What version of the Codex App are you using (From “About Codex” dialog)?

Installed Windows package at the time of the failure: OpenAI.Codex_26.901.6511.0_x64 (verified from the running executable path, rather than the About dialog).
Embedded Codex CLI: 0.153.4.

What subscription do you have?

Not included in this report.

What platform is your computer?

Native Windows, build 26200.9278, version 25H2; PowerShell. Not running the affected browser runtime in WSL.

What issue are you seeing?

The built-in browser starts and can read a public webpage in a managed read-only task, but its pageAssets.bundle() capability fails when creating its internal temporary output directory:

EPERM: operation not permitted, mkdir 'C:\Users\<user>\AppData\Local\Temp\browser-use'

Observed on 2026-09-07:

• Browser navigation, page inspection, screenshots, and pageAssets.list() worked.
• Bundling discovered product images failed with the error above.
• The failed tool call reported approximately 143 seconds elapsed.
• The failure surfaced as a raw filesystem error; the observed call did not successfully obtain an appropriate writable artifact location.

Effective settings:

sandbox_mode = "read-only"

[windows]
sandbox = "unelevated"

The task's filesystem policy granted root read access and no writable roots; auto-review was enabled. TEMP and TMP resolved to the normal host-user Windows Temp directory.

This report concerns handling of the helper's local write requirement, not a request to silently bypass read-only permissions.

What steps can reproduce the bug?

The following describes the observed failing sequence; a minimal cross-site browser reproduction has not yet been independently validated.

1. Run Codex Desktop natively on Windows with the unelevated sandbox implementation and a managed read-only task.
2. Start the in-app browser and navigate to a public page with images.
3. Confirm that page reading and screenshots work.
4. Obtain the tab's documented pageAssets capability and call list().
5. Call bundle() with the returned inventory ID and valid discovered image asset IDs.
6. Observe the local mkdir failure for %TEMP%\browser-use.

In the observed environment, %TEMP%\browser-use did not exist at the subsequent diagnostic inspection.

What is the expected behavior?

The capability should handle its local artifact-write requirement in accordance with the task's permissions:

• Use an explicitly permitted artifact/scratch location, or offer a supported output directory.
• If writing requires additional permission, route that requirement through an appropriate approval mechanism.
• If bundling is unavailable under the active policy, explain that limitation promptly before attempting the operation.

Users should not need Full Access, broad manual Temp ACL changes, or repeated per-directory repairs to use this capability. A read-only task should remain read-only except for properly authorized output.

Additional information

Controlled filesystem checks (not end-to-end browser fix verification):

Using the installed CLI's codex sandbox -P interface, fresh disposable directories/files were created, read back, and removed. Tests were launched outside the outer sandbox with authorization to avoid nesting restricted tokens.

The project was under OneDrive, but project writes succeeded in the latter two contexts. The host user's Temp ACL granted that user FullControl. No permanent ACL or active configuration changes were made. These controls point to the effective sandbox boundary rather than a general host-user filesystem failure.

Inspection of the locally shipped browser service showed the bundle path being formed as filesystem.tmpDir/browser-use/assets/<UUID>, followed by recursive mkdir; its filesystem adapter obtains tmpDir from node:os.tmpdir(). This explains the observed destination. It does not establish the intended architectural fix.

A narrower temporary profile allowing writes only to the project and the exact, initially absent %TEMP%\browser-use root still failed to create that cache root. That observation has not been separately reduced into its own reproduction.

Related, but different failure stage: #36260 describes the elevated/read-only runtime failing to load a staged kernel.js before browser startup. Here, with unelevated mode, browser startup succeeds and a later asset-bundling operation fails on a write.

The workspace-profile controls establish filesystem behavior only. The complete browser bundle operation has not been rerun under workspace permissions, so this report does not claim an end-to-end fix.

Please consider a regression test covering successful browser reads followed by asset bundling under read-only and workspace policies, including a missing cache directory and a fresh runtime start. Private conversation contents, account data, and identifying paths are omitted.

Start with the pageAssets.bundle() path and the sandbox policy handling around codex sandbox -P; inspect how the browser service derives its temporary directory from node:os.tmpdir(). Reproduce asset bundling after browser startup under read-only and workspace policies, including a missing cache directory. Done means read-only behavior is handled according to policy without raw mkdir failure, with regression coverage for both policies.