Image preview in the Code Editor file pane, with directory thumbnail strip

[NorfeldtKnowit]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates. Closest existing issues are Support displaying inline images #1693, Image protocols #5286, Support image display with viu #3953, and Support Image preview in ranger #3035, which all target the terminal grid path (escape-sequence rendering inside a shell). [Feature request] "Open with" in the context menu #2206 was about an external "Open with" submenu and was closed as not planned. None cover the GUI File Tree to Code Editor preview surface this request is about.
• I have searched Warp docs and my feature is not there. The Code Editor docs and File Tree docs describe text-file behavior only; the Markdown viewer is the closest precedent for a non-text view inside a Code Editor tab.

Describe the solution you'd like?

When clicking an image file in the File Tree (Project Explorer), open it in an Image Preview tab in the Code Editor instead of a text editor tab. The preview should behave as a lightweight photo browser.

Main view

• Fit-to-pane by default, preserving aspect ratio; no upscale beyond 100% by default.
• Cmd+= / Cmd+- / Cmd+0 for zoom in / out / reset; trackpad pinch zoom; click-and-drag pans when zoomed.
• Status footer always visible: filename, pixel dimensions, file size, format.
• Animated GIF, animated WebP, and animated AVIF auto-play and loop, with a play/pause toggle that persists across navigation.
• SVG renders as vector (re-rasterized at the current zoom level), sharp at any zoom.
• EXIF orientation honored for both the main view and thumbnails.

Thumbnail strip below the image

• Horizontal, virtualized strip listing supported images in the same directory, sorted by case-insensitive natural filename order (so img2 precedes img10).
• Current image highlighted; strip auto-scrolls to keep it visible.
• Left and Right arrows navigate previous and next; Home and End jump to first and last; navigation stops at the ends, no wrap.
• Click swaps the preview in place (single-tab photo-browser feel); Cmd+click opens the thumbnail in a new tab.
• Thumbnails decoded on a background thread pool, cached on disk keyed by (canonical path, mtime, size, target dimension); LRU eviction with a configurable cap (proposed default 256 MB).

Supported formats: .png, .jpg, .jpeg, .gif, .webp, .svg, .heic, .heif, .bmp, .tiff, .tif, .avif, .ico. Magic-byte sniff overrides the extension when they disagree.

Reuse: the existing Agent-context image pipeline (drag-drop, paste, decode, EXIF, downscale, shipped throughout the 2025-07 and 2025-08 changelog) already does the heavy lifting. This feature is largely a new view, a thumbnail-cache layer, and a router from File Tree click to view kind.

Out of scope (explicit non-goals): terminal-grid inline rendering (#1693, #5286), editing / cropping / annotation, RAW formats (CR2, NEF, ARW, DNG), PDFs, network or remote URLs, slideshow / full-screen presentation mode, image diffs across git revisions.

Sketch of the layout:

┌─────────── Code Editor tab: "logo@2x.png" ─────────────┐
│                                                          │
│                  [   image content   ]                   │
│                                                          │
│  Fit  100%  -  +    logo@2x.png  1024x1024  124 KB  PNG  │
├──────────────────────────────────────────────────────────┤
│ [thumb] [thumb] [THUMB*] [thumb] [thumb] [thumb] [thumb] │
└──────────────────────────────────────────────────────────┘

Is your feature request related to a problem? Please describe.

Today, clicking a .png, .jpg, .svg, .heic, or similar in the File Tree opens it as a text file in the Code Editor and shows binary bytes (or, for SVG, raw XML). To actually look at an image asset the user has to leave Warp for Finder, Files, or an external viewer, which breaks flow inside the agentic development environment Warp positions itself as.

This affects practically every front-end, mobile, design-systems, docs, and ML repo. A developer hits this within minutes of using the File Tree on any real project.

The terminal-grid image protocol path (iTerm2 / Kitty) does not solve it: that path only renders when a CLI tool emits escape sequences inside a shell, and a GUI File Tree click never goes through a shell. The "Open with" external-app route was closed as not planned in #2206. The remaining gap is an in-app preview in the Code Editor, and the Markdown viewer already establishes the precedent for a non-text view in the same tab system.

Additional context

Behavior invariants and a tech sketch are pre-drafted. I have a product.md (numbered testable behavior invariants covering format support, magic-byte routing, zoom/pan/fit math, thumbnail strip ordering and virtualization, animation, EXIF and color profiles, drag-and-drop into Agent prompts, error states, performance budget, accessibility, and tab-system integration) and a tech.md (MediaTypeRouter, ImagePreviewView, ZoomPanController, ThumbnailStripController, ThumbnailCache, settings additions, keybindings, file-touch list, testing matrix, risks around HEIC on Linux and animated AVIF). Both are ready to drop into specs/GH<issue-number>/ as soon as ready-to-spec is applied; happy to open the spec PR immediately after labeling.

Proposed performance budget. Thumbnail strip first paint under 100 ms with a cold cache for 50 images. Strip virtualized for directories with more than 500 images. Decoded full-size image memory dropped on tab close. Concurrent full-size decodes capped at one per tab. Thumbnail decode thread pool capped at min(num_cpus, 4).

Cross-platform notes.

• HEIC on Linux requires libheif. Needs a packaging and licensing note before commit.
• Color profile fidelity outside macOS documented as best-effort sRGB for v1.
• Animated AVIF may fall back to first-frame for v1 if the existing decoder lacks frame iteration; static AVIF stays in scope.

Reuse and integration.

• Decode, EXIF, downscale, color resample: existing Agent-context image pipeline.
• Tab system, drag-split-close, session restore: existing Code Editor tab controller.
• Directory change notifications: existing File Tree watcher (do not instantiate a second one).
• Drag from preview into Agent prompt: emit the same payload type as the existing Agent context attach drag; sink unchanged.

Related issues: #1693, #5286, #3953, #3035 (terminal-grid surface, different problem), #2206 (Open with, closed as not planned). Reference precedent: docs.warp.dev/terminal/more-features/markdown-viewer for a non-text view inside the Code Editor tab system.

Operating system (OS)

macOS (with Linux and Windows explicitly in scope per the proposed spec).

How important is this feature to you?

4

[oz-for-oss]

@NorfeldtKnowit

Here's what I found while triaging this issue:

This looks like a distinct feature request for an in-app Code Editor image preview, not a duplicate of the existing terminal inline-image requests (#1693/#3953) or external Open With requests (#2206/#3271). The current file-opening model has Markdown, code/text, external-editor, and system-open targets, but no image-preview target.

Maintainer details

I concluded that feature request for an in-Warp Image Preview tab launched from the File Tree, including zoom/pan controls and a same-directory thumbnail strip..

Initial triage

This is a well-specified enhancement request for a new in-app image preview surface in the Code Editor, entered from the File Tree / Project Explorer. It is not the same surface as terminal-grid inline image protocols or external Open With handling.

Code context

• app/src/code/file_tree/view.rs routes File Tree clicks through open_file, emits FileTreeEvent::OpenFile, and currently resolves a FileTarget before handing off to workspace-level opening.
• app/src/util/openable_file_type.rs defines the current file-open target model: MarkdownViewer, CodeEditor, external/editor options, and system-open options. There is no ImagePreview target. Raster formats such as png/jpg/gif/webp/bmp/tiff/ico are treated as binary by extension in crates/warp_util/src/file_type.rs; SVG is text and is therefore routed as a text/code-editor file.
• app/src/workspace/view.rs handles FileTarget::MarkdownViewer, FileTarget::CodeEditor, and system/external targets, but has no branch for an in-Warp media preview.
• app/src/code/view.rs constructs Code Editor tabs using LocalCodeEditorView and shared text buffers from app/src/code/global_buffer_model.rs; this tab model would need either a new pane/tab variant or a routed non-text view analogous to the Markdown viewer path.
• app/src/util/image.rs provides agent-mode image resize/validation utilities for attached images, but it is not a UI preview/thumbnail pipeline and currently lists only png/jpeg/gif/webp MIME types.

Duplicate check

I enumerated open non-PR issues via the GitHub API and checked recently closed issues from the last seven days. The closest matches are adjacent but distinct: #1693, #3953, #5286, and #3035 cover terminal inline image/protocol/ranger-preview behavior, while #2206 and #3271 cover external Open With flows. I did not find two or more existing open issues requesting this same File Tree → Code Editor image preview surface, so this should not be marked duplicate.

Suggested routing

Apply enhancement, area:editor-notebooks, area:workspace, needs-mocks, repro:high, and os:mac. Human maintainers should decide whether/when to apply reserved lifecycle labels such as ready-to-spec after reviewing the proposed spec materials.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[NorfeldtKnowit]

Thanks for the targeting, this matches the pre-drafted spec well. Materials at https://gist.github.com/NorfeldtKnowit/c5e0e8833b0fcac6e4d2f2dbd9322d82 covering 23 testable behavior invariants and a tech sketch.

I have updated tech.md to align with the integration points identified in triage: adding FileTarget::ImagePreview in app/src/util/openable_file_type.rs, reclassifying raster formats and SVG in crates/warp_util/src/file_type.rs, branching in app/src/workspace/view.rs parallel to the Markdown viewer path, registering the new view in app/src/code/view.rs and global_buffer_model.rs, and extending the existing agent-mode decoder in app/src/util/image.rs as the seed for a stable ImageDecoder.

Happy to draft a textual wireframe set for the needs-mocks review if useful; otherwise I will wait on lifecycle labeling. No rush.

[oz-for-oss]

This issue has been labeled ready-to-spec and is open for contributions in the form of a product or technical spec. If you'd like to draft one, feel free to open a pull request with the spec under specs/. You can also comment @oz-agent on this issue to have the bot draft the spec automatically.

[peicodes]

Thanks for the gist! We think this should be implemented using the Lightbox component, which would open up a preview overlay over your pane with the image.

Please open a PR with the specs for review