Add "Reveal in Finder" to code pane overflow menu by wzc520pyfm · Pull Request #10334 · warpdotdev/warp

wzc520pyfm · 2026-05-07T05:39:04Z

Description

Adds a Reveal in Finder item to the per-code-pane overflow (⋮) menu, with a Cmd+Option+R shortcut on macOS. Selecting it opens the active code tab's file in the platform's file manager (Finder on macOS, Explorer on Windows, or the system file manager on Linux) via AppContext::open_file_path_in_explorer.

The label is platform-aware (Reveal in Finder / Reveal in Explorer / Reveal in file manager), and the keystroke chip is driven by keybinding_name_to_keystroke, so user overrides set in Settings → Keybindings are reflected in the menu chip.

The work is split across two focused commits:

Add Reveal in Finder action to code pane overflow menu — new CodeViewAction::RevealInFinder variant + menu item + handler. The item is only emitted when the active tab has a resolvable local path (mirroring the existing Copy file path guard), and the variant is gated by the local_fs feature for the same reason.
Add Cmd+Option+R keybinding for Reveal in Finder — registers code_view:reveal_in_finder as an EditableBinding scoped to CodeEditorView with a default macOS keystroke; the menu item label switches to MenuItemFields::new_with_label so the chip displays the bound shortcut. Linux/Windows ship without a default to avoid clashing with common shortcuts there; users can still bind it themselves.

Linked Issue

Implements #10257.

The linked issue is labeled ready-to-spec or ready-to-implement.
Where appropriate, screenshots or a short video of the implementation are included below.

Testing

I have manually tested my changes locally with ./script/run

Manual verification on macOS:

Open a file in the code pane → click the pane's ⋮ menu → Reveal in Finder ⌥⌘R appears beneath Copy file path. Selecting it opens Finder at the file's location.
Pressing Cmd+Option+R while the editor is focused does the same.
The chip updates if the binding is overridden in Settings → Keybindings.
The entry is hidden when the active tab has no resolvable local path (e.g. unsaved buffers).

Why no integration test: the user-visible side effect is the platform's open_file_path_in_explorer call, which is implemented as a no-op in the test platform delegate (crates/warpui_core/src/platform/test/delegate.rs), so there is no observable post-condition for an integration assertion. In addition, the integration crate cannot directly reference CodeView / CodeViewAction (the code module is private to the warp crate) or MenuItem::fields() (#[cfg(test)]-gated) without expanding the public API surface just for the test. I'm happy to revisit this in a follow-up if reviewers would like a UI-driven smoke test or want to expose those internals behind a feature = "integration_tests" gate.

Screenshots / Videos

Screenshot showing the new menu entry will be added shortly — captured locally from ./script/run.

Agent Mode

Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Made with Cursor

Adds a `Reveal in Finder` item to the per-code-pane overflow menu (the `⋮` button next to the tab bar), placed right after `Copy file path`. Selecting it opens the active code tab's file in the platform's file manager (Finder on macOS, Explorer on Windows, otherwise the generic file manager) via `AppContext::open_file_path_in_explorer`. The menu item is only emitted when the active tab has a resolvable local path, mirroring the existing `Copy file path` guard so the behavior is consistent on remote / unsaved buffers, and the underlying `CodeViewAction::RevealInFinder` variant is gated by the `local_fs` feature for the same reason. Refs warpdotdev#10257. Co-authored-by: Cursor <cursoragent@cursor.com>

Registers `code_view:reveal_in_finder` as an `EditableBinding` scoped to the `CodeEditorView` context with a default macOS keystroke of `Cmd+Option+R`, so users can invoke the action without opening the overflow menu and can rebind it from Settings → Keybindings. Linux and Windows ship without a default to avoid clashing with common shortcuts on those platforms; users can still bind it themselves. The overflow menu label is now built with `MenuItemFields::new_with_label` and the keystroke is looked up via `keybinding_name_to_keystroke`, so any user-customized binding is reflected in the menu chip and the chip stays empty when no binding is defined. This mirrors the pattern already used by `Close saved` / `Close all` in this file. Co-authored-by: Cursor <cursoragent@cursor.com>

cla-bot · 2026-05-07T05:39:08Z

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @wzc520pyfm on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment @cla-bot check to trigger another check.

wzc520pyfm · 2026-05-07T05:45:13Z

@cla-bot check

oz-for-oss · 2026-05-07T05:45:26Z

@wzc520pyfm

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @kevinyang372.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

Adds a local-filesystem-gated code pane overflow action and editable keybinding to reveal the active code tab in the platform file manager.

Concerns

The editable keybinding description is macOS-specific even though the binding appears on every local filesystem platform.

Verdict

Found: 0 critical, 0 important, 1 suggestions

Approve with nits

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com>

cla-bot · 2026-05-07T06:23:28Z

The cla-bot has been summoned, and re-checked this pull request!

kevinyang372

This looks good! Can you get rid of the editable keybinding? I could approve and merge after that

kevinyang372 · 2026-05-07T17:58:04Z

        .with_context_predicate(id!("CodeEditorView"))
        .with_key_binding("cmdorctrl-r u"),
+        #[cfg(feature = "local_fs")]
+        EditableBinding::new(


I don't think we need an editable keybinding for this action

I have removed editable keybinding. And the local verification function is normal.

Removes the `code_view:reveal_in_finder` `EditableBinding` (and its `Cmd+Option+R` macOS default), the `REVEAL_IN_FINDER_BINDING_NAME` constant, the `keybinding_name_to_keystroke` lookup, and the `MenuItemFields::new_with_label` shortcut chip wiring. The overflow menu entry stays but is now built with a plain `MenuItemFields::new` without a keystroke chip. Per PR review, an editable binding adds noise to Settings → Keybindings for a low-frequency action that is already discoverable from the per-pane overflow menu. Users who want a shortcut can still add one themselves via Settings. Co-authored-by: Cursor <cursoragent@cursor.com>

kevinyang372

Thanks for contributing!

Close warpdotdev#10257 . ## Description Adds a `Reveal in Finder` item to the per-code-pane overflow (`⋮`) menu, with a `Cmd+Option+R` shortcut on macOS. Selecting it opens the active code tab's file in the platform's file manager (Finder on macOS, Explorer on Windows, or the system file manager on Linux) via `AppContext::open_file_path_in_explorer`. The label is platform-aware (`Reveal in Finder` / `Reveal in Explorer` / `Reveal in file manager`), and the keystroke chip is driven by `keybinding_name_to_keystroke`, so user overrides set in Settings → Keybindings are reflected in the menu chip. The work is split across two focused commits: 1. **Add Reveal in Finder action to code pane overflow menu** — new `CodeViewAction::RevealInFinder` variant + menu item + handler. The item is only emitted when the active tab has a resolvable local path (mirroring the existing `Copy file path` guard), and the variant is gated by the `local_fs` feature for the same reason. 2. **Add Cmd+Option+R keybinding for Reveal in Finder** — registers `code_view:reveal_in_finder` as an `EditableBinding` scoped to `CodeEditorView` with a default macOS keystroke; the menu item label switches to `MenuItemFields::new_with_label` so the chip displays the bound shortcut. Linux/Windows ship without a default to avoid clashing with common shortcuts there; users can still bind it themselves. ## Linked Issue Implements warpdotdev#10257. - [x] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. - [x] Where appropriate, screenshots or a short video of the implementation are included below. ## Testing - [x] I have manually tested my changes locally with `./script/run` Manual verification on macOS: - Open a file in the code pane → click the pane's `⋮` menu → `Reveal in Finder ⌥⌘R` appears beneath `Copy file path`. Selecting it opens Finder at the file's location. - Pressing `Cmd+Option+R` while the editor is focused does the same. - The chip updates if the binding is overridden in Settings → Keybindings. - The entry is hidden when the active tab has no resolvable local path (e.g. unsaved buffers). **Why no integration test**: the user-visible side effect is the platform's `open_file_path_in_explorer` call, which is implemented as a no-op in the test platform delegate (`crates/warpui_core/src/platform/test/delegate.rs`), so there is no observable post-condition for an integration assertion. In addition, the integration crate cannot directly reference `CodeView` / `CodeViewAction` (the `code` module is private to the `warp` crate) or `MenuItem::fields()` (`#[cfg(test)]`-gated) without expanding the public API surface just for the test. I'm happy to revisit this in a follow-up if reviewers would like a UI-driven smoke test or want to expose those internals behind a `feature = "integration_tests"` gate. ### Screenshots / Videos _Screenshot showing the new menu entry will be added shortly — captured locally from `./script/run`._ <img width="1280" height="800" alt="Snipaste_menu_action_item" src="https://github.com/user-attachments/assets/436d0b07-3e15-47b9-abce-9ec40d8af877" /> <img width="1286" height="800" alt="Snipaste_menu_action_open_finder" src="https://github.com/user-attachments/assets/793bb4a9-8daa-4163-b1d9-5cf5bcf42d4f" /> ## Agent Mode - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com>

Close warpdotdev#10257 . Adds a `Reveal in Finder` item to the per-code-pane overflow (`⋮`) menu, with a `Cmd+Option+R` shortcut on macOS. Selecting it opens the active code tab's file in the platform's file manager (Finder on macOS, Explorer on Windows, or the system file manager on Linux) via `AppContext::open_file_path_in_explorer`. The label is platform-aware (`Reveal in Finder` / `Reveal in Explorer` / `Reveal in file manager`), and the keystroke chip is driven by `keybinding_name_to_keystroke`, so user overrides set in Settings → Keybindings are reflected in the menu chip. The work is split across two focused commits: 1. **Add Reveal in Finder action to code pane overflow menu** — new `CodeViewAction::RevealInFinder` variant + menu item + handler. The item is only emitted when the active tab has a resolvable local path (mirroring the existing `Copy file path` guard), and the variant is gated by the `local_fs` feature for the same reason. 2. **Add Cmd+Option+R keybinding for Reveal in Finder** — registers `code_view:reveal_in_finder` as an `EditableBinding` scoped to `CodeEditorView` with a default macOS keystroke; the menu item label switches to `MenuItemFields::new_with_label` so the chip displays the bound shortcut. Linux/Windows ship without a default to avoid clashing with common shortcuts there; users can still bind it themselves. Implements warpdotdev#10257. - [x] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. - [x] Where appropriate, screenshots or a short video of the implementation are included below. - [x] I have manually tested my changes locally with `./script/run` Manual verification on macOS: - Open a file in the code pane → click the pane's `⋮` menu → `Reveal in Finder ⌥⌘R` appears beneath `Copy file path`. Selecting it opens Finder at the file's location. - Pressing `Cmd+Option+R` while the editor is focused does the same. - The chip updates if the binding is overridden in Settings → Keybindings. - The entry is hidden when the active tab has no resolvable local path (e.g. unsaved buffers). **Why no integration test**: the user-visible side effect is the platform's `open_file_path_in_explorer` call, which is implemented as a no-op in the test platform delegate (`crates/warpui_core/src/platform/test/delegate.rs`), so there is no observable post-condition for an integration assertion. In addition, the integration crate cannot directly reference `CodeView` / `CodeViewAction` (the `code` module is private to the `warp` crate) or `MenuItem::fields()` (`#[cfg(test)]`-gated) without expanding the public API surface just for the test. I'm happy to revisit this in a follow-up if reviewers would like a UI-driven smoke test or want to expose those internals behind a `feature = "integration_tests"` gate. _Screenshot showing the new menu entry will be added shortly — captured locally from `./script/run`._ <img width="1280" height="800" alt="Snipaste_menu_action_item" src="https://github.com/user-attachments/assets/436d0b07-3e15-47b9-abce-9ec40d8af877" /> <img width="1286" height="800" alt="Snipaste_menu_action_open_finder" src="https://github.com/user-attachments/assets/793bb4a9-8daa-4163-b1d9-5cf5bcf42d4f" /> - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com> (cherry picked from commit 10e2bae)

Close warpdotdev#10257 . ## Description Adds a `Reveal in Finder` item to the per-code-pane overflow (`⋮`) menu, with a `Cmd+Option+R` shortcut on macOS. Selecting it opens the active code tab's file in the platform's file manager (Finder on macOS, Explorer on Windows, or the system file manager on Linux) via `AppContext::open_file_path_in_explorer`. The label is platform-aware (`Reveal in Finder` / `Reveal in Explorer` / `Reveal in file manager`), and the keystroke chip is driven by `keybinding_name_to_keystroke`, so user overrides set in Settings → Keybindings are reflected in the menu chip. The work is split across two focused commits: 1. **Add Reveal in Finder action to code pane overflow menu** — new `CodeViewAction::RevealInFinder` variant + menu item + handler. The item is only emitted when the active tab has a resolvable local path (mirroring the existing `Copy file path` guard), and the variant is gated by the `local_fs` feature for the same reason. 2. **Add Cmd+Option+R keybinding for Reveal in Finder** — registers `code_view:reveal_in_finder` as an `EditableBinding` scoped to `CodeEditorView` with a default macOS keystroke; the menu item label switches to `MenuItemFields::new_with_label` so the chip displays the bound shortcut. Linux/Windows ship without a default to avoid clashing with common shortcuts there; users can still bind it themselves. ## Linked Issue Implements warpdotdev#10257. - [x] The linked issue is labeled `ready-to-spec` or `ready-to-implement`. - [x] Where appropriate, screenshots or a short video of the implementation are included below. ## Testing - [x] I have manually tested my changes locally with `./script/run` Manual verification on macOS: - Open a file in the code pane → click the pane's `⋮` menu → `Reveal in Finder ⌥⌘R` appears beneath `Copy file path`. Selecting it opens Finder at the file's location. - Pressing `Cmd+Option+R` while the editor is focused does the same. - The chip updates if the binding is overridden in Settings → Keybindings. - The entry is hidden when the active tab has no resolvable local path (e.g. unsaved buffers). **Why no integration test**: the user-visible side effect is the platform's `open_file_path_in_explorer` call, which is implemented as a no-op in the test platform delegate (`crates/warpui_core/src/platform/test/delegate.rs`), so there is no observable post-condition for an integration assertion. In addition, the integration crate cannot directly reference `CodeView` / `CodeViewAction` (the `code` module is private to the `warp` crate) or `MenuItem::fields()` (`#[cfg(test)]`-gated) without expanding the public API surface just for the test. I'm happy to revisit this in a follow-up if reviewers would like a UI-driven smoke test or want to expose those internals behind a `feature = "integration_tests"` gate. ### Screenshots / Videos _Screenshot showing the new menu entry will be added shortly — captured locally from `./script/run`._ <img width="1280" height="800" alt="Snipaste_menu_action_item" src="https://github.com/user-attachments/assets/436d0b07-3e15-47b9-abce-9ec40d8af877" /> <img width="1286" height="800" alt="Snipaste_menu_action_open_finder" src="https://github.com/user-attachments/assets/793bb4a9-8daa-4163-b1d9-5cf5bcf42d4f" /> ## Agent Mode - [ ] Warp Agent Mode - This PR was created via Warp's AI Agent Mode  Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com>

wzc520pyfm and others added 2 commits May 7, 2026 13:18

github-actions Bot added the external-contributor Indicates that a PR has been opened by someone outside the Warp team. label May 7, 2026

wzc520pyfm marked this pull request as ready for review May 7, 2026 05:45

oz-for-oss Bot reviewed May 7, 2026

View reviewed changes

Comment thread app/src/code/view.rs Outdated

oz-for-oss Bot requested a review from kevinyang372 May 7, 2026 05:51

Apply suggestions from code review

fb03a66

Co-authored-by: oz-for-oss[bot] <277970191+oz-for-oss[bot]@users.noreply.github.com>

cla-bot Bot added the cla-signed label May 7, 2026

kevinyang372 reviewed May 7, 2026

View reviewed changes

wzc520pyfm force-pushed the wzc520pyfm/add-reveal-in-findeer branch from 3ab05a0 to c3ff288 Compare May 8, 2026 02:21

wzc520pyfm requested a review from kevinyang372 May 8, 2026 02:29

kevinyang372 approved these changes May 8, 2026

View reviewed changes

kevinyang372 merged commit 10e2bae into warpdotdev:master May 8, 2026
30 of 38 checks passed

wzc520pyfm deleted the wzc520pyfm/add-reveal-in-findeer branch May 8, 2026 06:17

timomak mentioned this pull request May 10, 2026

[twarp upstream] terminal timomak/twarp#36

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add "Reveal in Finder" to code pane overflow menu#10334

Add "Reveal in Finder" to code pane overflow menu#10334
kevinyang372 merged 4 commits into
warpdotdev:masterfrom
wzc520pyfm:wzc520pyfm/add-reveal-in-findeer

wzc520pyfm commented May 7, 2026 •

edited

Loading

Uh oh!

cla-bot Bot commented May 7, 2026

Uh oh!

wzc520pyfm commented May 7, 2026

Uh oh!

oz-for-oss Bot commented May 7, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

Uh oh!

cla-bot Bot commented May 7, 2026

Uh oh!

kevinyang372 left a comment

Uh oh!

kevinyang372 May 7, 2026

Uh oh!

wzc520pyfm May 8, 2026 •

edited

Loading

Uh oh!

kevinyang372 left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

wzc520pyfm commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Linked Issue

Testing

Screenshots / Videos

Agent Mode

Uh oh!

cla-bot Bot commented May 7, 2026

Uh oh!

wzc520pyfm commented May 7, 2026

Uh oh!

oz-for-oss Bot commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

Uh oh!

cla-bot Bot commented May 7, 2026

Uh oh!

kevinyang372 left a comment

Choose a reason for hiding this comment

Uh oh!

kevinyang372 May 7, 2026

Choose a reason for hiding this comment

Uh oh!

wzc520pyfm May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kevinyang372 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

wzc520pyfm commented May 7, 2026 •

edited

Loading

oz-for-oss Bot commented May 7, 2026 •

edited

Loading

wzc520pyfm May 8, 2026 •

edited

Loading