openai / openai/codex

Codex stores ~21 MB of invisible Computer Use screenshots and Remote cannot load the task

Open
#43,357 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug computer-use connectivity Linux remote
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using?

26.901.41600

What subscription do you have?

Not verified during this diagnostic.

What platform is your computer?

Fedora Linux 44 (Workstation Edition)

Linux 7.1.13-200.fc44.x86_64 x86_64 unknown

The task was hosted by the native Linux ChatGPT/Codex desktop app and opened through ChatGPT Remote on a phone.

What issue are you seeing?

A screenshot-heavy Computer Use task has two coupled problems:

  1. Neither the local desktop conversation nor the Remote conversation exposes the captured screenshots as reviewable evidence.
  2. The invisible screenshot payloads still make the task persistently impossible to open through ChatGPT Remote.

Attempting to open that one task caused the Remote connection to reset with ECONNRESET / EPIPE. Other tasks on the same connected computer remained accessible.

The failure was reproduced repeatedly for the same task. It persisted after rebooting, clearing cache, closing the Remote connection, and reconnecting. Those recovery actions did not make the affected task load.

After returning to the desktop, the task opened locally, but its visible transcript contained zero screenshots. The screenshots existed only as model/tool execution data inside the rollout JSONL. If those images had appeared as useful execution evidence, the payload cost would at least have served a visible purpose. Instead, the user receives neither the evidence nor a remotely loadable task.

The task is not corrupt. The failure correlates with a single very large turn containing inline base64 images that neither visible transcript renders.

Current read-only measurements of the task record (it continued growing after the original Remote failure):

  • Session/task ID: 01a077ee-681c-79e1-bb48-3c4e8d54a826
  • JSONL size: 35,907,078 bytes across 2,586 records
  • Embedded image occurrences: 77 total (69 JPEG, 8 PNG)
  • Unique embedded image payloads: 71 (64 JPEG, 7 PNG)
  • Unique inline image-string bytes: 20,913,042
  • Largest turn: 21,130,394 bytes, 762 records, 62 image occurrences
  • 55 image occurrences are under payload.item.result._meta.codex/toolSurface.screenshot.url
  • 17 are under function-call payload.output[].image_url
  • 5 are under model-facing payload.content[].image_url

No JSONL, screenshots, credentials, or task content are attached because the task includes private browser work.

Steps to reproduce
  1. Start a local Codex desktop task on a computer connected to ChatGPT Remote.
  2. Use Computer Use repeatedly within one long turn so the tool surface captures many screenshots.
  3. Do not publish those screenshots as visible assistant images.
  4. Allow the raw task rollout to accumulate many inline data:image/*;base64,... values in one turn.
  5. Inspect the task locally and observe that the conversation exposes none of the captured screenshots.
  6. From ChatGPT Remote on a phone, open that task.
  7. Observe that the task fails to load and the Remote connection resets, while smaller tasks on the same host continue to open.
  8. Reboot, clear cache, close the Remote connection, and reconnect.
  9. Observe that the same task still fails repeatedly.

This report describes one affected task, not a fully automated minimal reproduction. The failure was persistent and repeatedly observed for that task. The strongest differentiator was per-turn concentration: the problematic task had approximately 21 MB in one turn.

What is the expected behavior?

Computer Use screenshots retained as execution evidence should be reviewable from the local task and, where supported, through Remote.

Regardless of whether screenshots are exposed in the UI, invisible model/tool context must not prevent the visible task from loading remotely.

Screenshots needed for model continuation, audit, or optional review should be stored once as content-addressed blobs and represented in the event stream by references. Clients should fetch them lazily only when displayed or otherwise needed. At minimum, loading the visible conversation should not require eagerly transporting every inline base64 screenshot from model-only tool history.

If the current format cannot be changed immediately, Remote should paginate or omit non-visible image payloads and return a recoverable error instead of dropping the entire connection.

Additional information

The official Remote documentation says users can review task outputs and screenshots remotely. Retaining screenshot evidence is therefore reasonable. The bug is that the screenshots are not visible as evidence in this task, while their inline representation still breaks Remote access.

This may span two components:

  • Open-source Codex App Server / rollout serialization.
  • Closed ChatGPT desktop or Remote client synchronization and rendering.

The task remained usable locally and required no data repair.

Contact: John Pezzulli, jpezzulli@gmail.com

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the rollout JSONL and the open-source Codex App Server serialization path, then trace how ChatGPT Remote loads a task containing inline data-image values. Compare visible transcript handling with model/tool history handling. Done means screenshot-heavy tasks load remotely without resetting the connection and retained screenshots are either reviewable or safely omitted from visible-task loading.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend, desktop
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.