Skip to content

Tab config repo picker truncates long paths with no way to see, scroll, or alias them #9439

@saucy-tech

Description

@saucy-tech

Summary

The repo picker used by tab config type = "repo" parameters truncates long entries with no way to see the rest of the path, scroll horizontally, hover for a tooltip, or attach a friendly nickname/alias. When several saved repos live deep inside paths like ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/... or ~/Library/CloudStorage/GoogleDrive-<email>/..., the visible portion of two different entries can be byte-for-byte identical, making it impossible to tell them apart at the moment of selection.

Problem

Tab configs make it easy to launch flows like "open Claude in a project" by declaring a [params.<name>] type = "repo" parameter. On open, Warp shows a dropdown of saved repos so the user can pick which directory to launch in.

Today that dropdown:

  • Renders each entry as the raw absolute path.
  • Has a fixed dropdown width with single-line entries.
  • Truncates the tail of long paths with an ellipsis.
  • Does not appear to expose hover/tooltip, horizontal scroll, mid-path elision, or any user-defined display name.

In practice this means:

  • Two different repos that share a long common prefix (for example two projects under the same iCloud Documents folder) collapse into visually identical rows ending in . The user cannot reliably pick the right one without trial and error.
  • The most distinctive part of a path (typically the trailing repo/project name) is exactly the part that gets cut off.
  • The search box at the top filters by the underlying path, but the user can't always remember the exact prefix to type, especially for cloud-sync paths with vendor-specific tokens like iCloud~md~obsidian or GoogleDrive-<email>.

This is mostly a UX issue for users who keep work in nested cloud-sync folders, monorepos, or any directory with a deep parent chain.

Expected behavior

A user opening a tab config that uses a repo parameter should always be able to identify the full path of each entry in the picker, and ideally label entries with a friendly name they choose.

Reasonable ways to satisfy this (any one or a combination would help):

  1. Show the full path on demand via a tooltip on hover, by widening the dropdown to the longest entry up to a sensible cap, or by allowing the dropdown to scroll horizontally.
  2. Smart elision in the middle of the path instead of the end, so the trailing project/repo name is always visible (e.g. /Users/brandon/Library/…/obsidian/Documents/<project>). macOS Finder and several IDE quick-open palettes use this pattern.
  3. User-defined nicknames / aliases for saved repos, surfaced as the primary label in the picker, with the full path shown as secondary text underneath or on hover. This could be done either:
    • via a per-repo nickname stored alongside the saved repo entry in Warp's persisted workspace state, edited from a "rename" action in the picker, or
    • via an optional display_name / alias field declared per [params.<name>] type = "repo" entry in the tab config TOML schema (less likely to scale because the schema doesn't own the saved-repo list).
  4. Two-line rows showing the basename prominently and the full path as muted secondary text, similar to VS Code's "Open Recent" picker.

Any of these would unblock the underlying need: "let me reliably distinguish saved repos at the moment of selection."

Actual behavior

Long paths are visually cut off with an ellipsis at a fixed dropdown width, and there is no hover, scroll, alias, or alternate display mode to recover the missing characters. Entries that share a long prefix become indistinguishable.

Reproduction steps or desired workflow

  1. Save several repos to Warp's project list whose absolute paths share a long common prefix and exceed the dropdown's visible width. Concrete examples that reproduce the issue cleanly on macOS:
    • ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/<project A>
    • ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/<project B>
    • ~/Library/CloudStorage/GoogleDrive-<email>/My Drive/<project>
  2. Create or use a tab config that declares a repo parameter, e.g.:
    name = "Open Project (Claude)"
    
    [[panes]]
    id = "main"
    type = "agent"
    directory = "{{project}}"
    commands = ["claude"]
    
    [params.project]
    type = "repo"
    description = "Choose repo"
  3. Open the tab config from the + menu so the params modal appears.
  4. Click the project field to open the repo picker.
  5. Observe that the iCloud and Google Drive entries are truncated mid-path with , and that two distinct entries can render with identical visible text.

Artifacts

Screenshot 1: Tab config repo picker showing the Open: 🧡 Open modal with Choose repo dropdown; multiple entries under ~/Library/Mobile Documents/iCloud~md~obsidian/... and ~/Library/CloudStorage/GoogleDrive-... are truncated at the right edge with a trailing ellipsis, hiding the part of the path that would distinguish them.

Image

Warp version

v0.2026.04.27.15.33.preview_02

Operating system

macOS (version not specified by reporter; inferred from /Users/<name>/Library/... paths in the screenshot)

Possible source references

  • app/src/tab_configs/repo_picker.rs — defines the picker shown for type = "repo" parameters; contains a DEFAULT_DROPDOWN_WIDTH constant (380.0) and renders each entry as a single line of raw path text via path.to_string_lossy(). This is the natural place to introduce a wider/auto-sized dropdown, mid-path elision, a hover tooltip, or a richer per-entry render that surfaces an alias.
  • app/src/tab_configs/params_modal.rs — hosts the parameter modal that embeds the repo picker; relevant if the fix needs to coordinate with sibling controls (search input, footer).
  • app/src/tab_configs/mod.rs — top-level tab config wiring; relevant if any new schema field (e.g. an optional alias) is added.

Metadata

Metadata

Assignees

Labels

area:launch-configsLaunch configurations, workflows, tab configs, and automation entry points.enhancementNew feature or request.ready-to-implementThe issue is ready for implementation work.repro:highThe report includes enough evidence that the issue appears highly reproducible.triagedIssue has received an initial automated triage pass.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions