Codex 0.161: denied reads stay denied, so a Sume upload may fail
Codex 0.161.0 lets approved filesystem escalation widen writes while keeping denied reads. Why a local file upload to Sume can still fail, and how to fix it.

If Codex cannot read a file, it cannot upload it to Sume, even after you approve a broader write escalation. The Codex changelog for 0.161.0, dated October 7, 2026, says approved filesystem escalation can grant broader write access while preserving denied reads and network restrictions. Sume's hosted MCP cannot read files from your computer, so any local upload has to be read by the client process first.
That combination catches people who give an agent an image to animate: the escalation prompt looks like it opened everything, yet a denied read is still denied.
How a local file reaches Sume
Sume's docs describe the upload flow in three steps.
| Step | Tool or action | Can the sandbox block it? |
|---|---|---|
| 1 | assets_upload_url returns a URL (needs idempotency_key) | No, it is a remote call |
| 2 | The client reads the file and PUTs the bytes to that URL | Yes: a denied read stays denied, and network restrictions are preserved |
| 3 | assets_complete finishes the asset (needs idempotency_key) | No, it is a remote call |
| 4 | Use the asset in a generation call | Only if step 2 worked |
Steps if the upload fails
First, check where the file lives. A file in a denied path will not be read whatever you approve for writes. Copy it to the working directory, or change the read rule, and retry. Second, check network. If the sandbox restricts outbound hosts, the PUT to the upload URL needs permission, separate from the MCP host. Third, retry the whole flow with a fresh idempotency_key for the new assets_upload_url call; do not reuse the old URL.
- Keep source images inside the project folder the agent can read.
- Allow
mcp.sume.comand the upload host the tool returns. - Ask for
dry_run=truebefore any paid generation that uses the asset.
A worked failure
Picture a folder where the sandbox denies reads of a private/ directory, and a product photo sits in it. You approve a write escalation so the agent can save results elsewhere. The agent then calls assets_upload_url, which succeeds, and tries to read the photo for the PUT. The read is denied, so the PUT never happens, and assets_complete would register an empty or missing upload. The agent may report a vague failure.
The fix is boring: move or copy the photo into a readable folder, and tell the agent to read the file before it asks Sume for an upload URL. Failing early avoids a half-finished asset record.
What Sume does not do
Sume does not reach into the sandbox, and it cannot see why a read failed. The server only gets calls that the client chose to make. A failed read shows up in the Codex output as a local error, not as a Sume error, so check there first.
Sources
Related posts
More in Integrations
- Codex bearer_token_env_var for Sume MCP: keep the key out of config
Codex can read a bearer token from an environment variable, so your Sume API key never lands in config.toml. Setup, the OAuth alternative, and what to check.
- Codex tool_timeout_sec is 60: size Sume jobs_wait to fit under it
Codex stops a tool call after 60 seconds by default. Sume jobs_wait holds at most 55 seconds, so one slice fits. Here is the loop and the config.
- Xcode and JetBrains Copilot: connect Sume MCP with requestInit headers
Copilot in Xcode and JetBrains sends remote MCP auth through requestInit headers. Here is the Sume API key entry, what it unlocks, and how to test it.
- Gemini CLI 0.64 preview moves settings to V2: recheck Sume
The 0.64.0 preview moves settings from V1 to V2. After you upgrade, confirm the Sume hosted MCP server still connects with a free read before any paid call.
Written by Sume