Feature request: robust remote previews for videos and correctly rendered PDFs

Open 💬 5 comments Opened Jun 19, 2026 by abcjhby2871
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Codex App should provide a reliable artifact preview/opening path for files generated in a remote workspace, especially:

  • Video artifacts such as .mp4, .webm, .mov, and .gif.
  • PDF artifacts generated by LaTeX/XeLaTeX or research/report pipelines.
  • PDFs containing non-Latin text, CJK text, Unicode symbols, math fonts, embedded fonts, and selectable text layers.

When Codex is connected to a remote/SSH workspace and a command generates an artifact, the app should be able to preview or open that artifact directly from the conversation or workspace file browser, without requiring the user to set up a separate HTTP server, SSH tunnel, file copy, or external viewer.

Current pain point

A common Codex workflow is to run long experiments or document-generation jobs remotely, then inspect the generated outputs before deciding the next instruction. For example:

  • A video-generation or visualization task produces preview.mp4, demo.gif, or a contact sheet.
  • A LaTeX/XeLaTeX build produces paper.pdf, report.pdf, or slides.pdf.
  • A research workflow needs the user to inspect whether the rendered PDF text, equations, CJK characters, and embedded fonts are correct.

Today, remote artifact review is not reliable enough for these workflows. In practice, users often have to manually download the file, expose the workspace with a temporary server, forward a port, or open a separate remote viewer just to inspect the artifact.

There is already a closely related issue for media artifacts in remote mobile Codex: #25202. This feature request is the broader version of that need: a consistent remote artifact preview/opening path across Codex App surfaces, including both video previews and high-fidelity PDF rendering.

There is also a separate PDF preview-size request in #26805. This request is different: it is primarily about rendering correctness and remote preview/opening behavior, not only the maximum previewable file size.

Expected behavior

For videos:

  • Show an inline thumbnail or preview card for common video formats.
  • Allow playback from the Codex App when the artifact is produced in a remote workspace.
  • Provide an “Open” or “Download” action backed by a secure relay/attachment mechanism if inline playback is not feasible.
  • Avoid relying on local filesystem paths that are meaningful only on the remote host.

For PDFs:

  • Render PDFs with embedded fonts correctly.
  • Preserve CJK/Unicode/XeLaTeX text rendering.
  • Render math symbols and equations correctly.
  • Preserve selectable/searchable text when the PDF contains a text layer.
  • Provide a fallback “Open externally” or “Download” action when inline rendering fails.
  • Surface a clear error when a PDF cannot be rendered, rather than silently showing broken/missing text.

For remote workspaces generally:

  • Files linked by the assistant from the workspace should be openable from the client UI.
  • Files selected in the workspace file browser should use the same preview/opening mechanism.
  • The behavior should be consistent across local and remote sessions as much as possible.

Why this matters

Codex is increasingly useful for long-running remote development and research workflows. Many important outputs are not plain text diffs:

  • ML/video generation experiments produce videos, GIFs, and visual previews.
  • Computer vision workflows produce rendered videos, contact sheets, masks, and figures.
  • Academic/research workflows produce LaTeX/XeLaTeX PDFs with equations and multilingual text.
  • UI and documentation workflows produce visual artifacts that need quick inspection before the next iteration.

Without reliable remote artifact preview, the user has to leave Codex to inspect results. That breaks the feedback loop: Codex can run the experiment, but the user cannot conveniently verify whether the output is correct before giving the next instruction.

Possible implementation direction

One possible design would be to treat generated workspace artifacts as first-class previewable attachments:

  • The remote host/app-server exposes artifacts through a secure, temporary relay or signed attachment URL.
  • The client UI renders supported formats inline where possible.
  • Unsupported or failed previews still get a reliable download/open action.
  • PDF rendering uses a mature renderer with embedded-font/CJK/Unicode support, with clear fallback behavior.

The exact implementation is up to the Codex team, but the important user-facing requirement is: remote-generated videos and PDFs should be easy to inspect from the Codex App itself.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #27563

Powered by Codex Action

piqiuni · 1 month ago

Video Preview Need

KeyffMS · 1 month ago

I have the similar requirement for arbitrary files in an SSH remote workspace,
not only videos and PDFs.

Example:

  • Codex App for Windows
  • project opened through an SSH remote connection
  • Codex generates a .tar.gz archive on the remote server
  • the archive is visible in the Codex file browser
  • there is no context-menu action to download it to the local Windows machine

Expected behavior:

Right click the remote file → Download... → select a local Windows destination.

Currently the only workarounds are scp or opening the workspace in VS Code Remote SSH.

abcjhby2871 · 1 month ago

Update: video preview now works in messages, but not in the workspace file tree

In the current Codex Desktop build (26.715.31925, macOS arm64), video artifacts referenced directly in assistant messages can now be previewed or played. However, selecting the same video file in the workspace file tree still does not provide a preview.

Folder paths referenced in assistant messages are also still non-actionable:

  • no directory preview or contents view;
  • no “Reveal in file tree” behavior;
  • no automatic selection/expansion of the referenced folder;
  • no convenient Copy Path action;
  • remote SSH paths are exposed as host paths rather than usable client-side actions.

Expected behavior

  1. Files opened from assistant messages and files opened from the workspace file tree should use the same preview pipeline.
  2. Clicking a folder path in a message should reveal, select, and expand that folder in the file tree, or open a lightweight directory-content view.
  3. Files and folders should consistently expose actions such as:
  • Preview
  • Reveal in file tree
  • Copy relative path
  • Copy absolute path
  • Open externally
  • Download, for remote workspaces
  1. Local and SSH remote workspaces should behave consistently.

The new message-level video preview is useful progress, but this issue is not fully resolved until the file-tree and folder-reference workflows use the same artifact handling path.

marks0kolov · 1 month ago

Yes, since the introduction of remotion, a video preview feature would be very well appreciated!