Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Add icon-theme support to the Project Explorer / File Tree so users can pick — and the community can contribute — icon sets, instead of being limited to Warp's fixed built-in glyphs.

Sketch of the desired behavior:

• A new File Tree icon theme picker under Settings → Appearance (parallel to terminal themes), with a small bundled set: today's default plus one community-style theme (Seti- or Material-inspired).
• A theme file format with the resolution order every file-tree theme converges on: exact filename → extension → language ID → folder name (open/closed) → fallback. Special-case folders like .git, node_modules, src, dist should be expressible.
• Themes loaded from a discoverable folder, so the community contributes via PR — the same model that made Warp's terminal-theme catalog grow.
• Two viable source formats; either is acceptable for v1:
  • SVG-based, like VS Code's File Icon Theme spec (used by Material Icon Theme and vscode-icons).
  • Nerd Font codepoint maps, like nvim-tree, yazi, lf. Lower lift if SVG rendering is too much for v1.

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

Warp's File Tree ships a fixed built-in icon set with no theming hooks. The docs say so directly: "Warp supports icons for common file types. If a file type is missing an icon, please file a GitHub issue so we can review and add support."

Two consequences:

1. Every missing or wrong icon becomes an inbound triage task for the Warp team, instead of a community PR. The terminal-theme catalog scales precisely because it's user-contributable; the file-tree icon set is on the opposite trajectory.
2. Users coming from another editor have no way to bring their preferred look across. Visual differentiation of file types isn't polish — it's how a tree gets scanned at a glance. Now that Warp positions itself as an agentic development environment, the Project Explorer is on the critical path for navigation, not a side panel.

Additional context

Prior art for the format — any is a fine starting point:

• VS Code File Icon Themes — JSON with iconDefinitions + fileExtensions / fileNames / languageIds / folderNames.
• Zed icon themes — newer, similar shape, single file.
• Nerd Font glyph maps as used by nvim-tree, yazi, lf.

Scoping suggestions to keep the first cut small (the spec PR is the right place to settle these — listing here so triage can see it's bounded):

• v1: two bundled themes + a read-only documented theme format. No in-app editor.
• User-defined themes loaded from a config folder: follow-up.
• SVG rendering is the bigger lift; if too much for v1, ship Nerd Font codepoints first and gate SVG behind a follow-up.

Non-goals (stated up front so the spec stays tight):

• Not a generalized extension API — just the icon-theme slice.
• No per-file user-level overrides in v1.
• No icon recoloring beyond what the theme file declares.

Related:

• VS Code-like Layout (Explorer + Editor + Terminal) #7488 (VS Code-like layout) overlaps in spirit but is much broader; this request is deliberately narrow.
• Project Explorer doesn't support chinese character #8041 (Project Explorer Chinese characters) is unrelated but in the same area.

Operating system (OS)

macOS

How important is this feature to you?

3