Pre-submit Checks

• I have searched Warp bugs and there are no exact duplicates
• I have searched Warp known issues page and my issue is not there

Describe the bug

When right-clicking in Windows File Explorer and selecting "Open Warp in new tab", the new Warp tab opens at ~ (USERPROFILE / home directory) instead of the directory where the right-click occurred.

This appears to be the Windows counterpart of issue #6665 (which reports the same behavior on Linux via "Open in Terminal" context menu).

To reproduce

1. Open any folder in Windows File Explorer (e.g. C:\Projects\my-app)
2. Right-click on empty space in the folder
3. Select "Open Warp in new tab" from the context menu
4. Warp opens a new tab, but pwd is ~ (e.g. C:\Users\<username>) instead of C:\Projects\my-app

Expected behavior

Warp should open the new tab with the working directory set to the folder where the right-click context menu was invoked.

Actual behavior

Warp opens at USERPROFILE (e.g. C:\Users\<username>), ignoring the directory context entirely.

Operating system (OS)

Windows

Operating system and version

Windows 10 (Build 26200.4061)

Current Warp version

Latest stable (as of May 2025)

Regression

No, this bug has existed throughout my experience using Warp on Windows.

Technical analysis

Based on a review of the Warp source code, here is a likely root cause:

1. URI handler parsing: The on_open_urls handler parses incoming URLs via Url::parse() and extract_filepath(). For file:// URIs with no host component, it attempts to prepend a drive letter by scanning for the first : or \.

2. Shell extension format mismatch: The Windows shell extension likely passes bare Windows paths (e.g. C:\Users\user\folder) rather than properly formatted file:/// URIs. When Url::parse() receives a bare path like C:\Users\user\folder, it fails because the C: is interpreted as a scheme rather than a drive letter.

3. Silent fallback: When URL parsing fails, the path is silently dropped. The window spawn logic then falls back to std::env::var_os("USERPROFILE") when initial_directory is None, resulting in the home directory being used.

4. Possible mitigation: The warp://warp/new_from_path endpoint exists for shell integration and may be the intended mechanism, but it appears the shell extension's context menu action doesn't invoke it correctly (or at all).

Suggested investigation areas:

• Check how the Windows shell extension serializes the directory path when invoking "Open Warp in new tab"
• Verify whether Url::parse() handles bare Windows paths (with drive letters) correctly
• Consider adding a fallback path parser that handles bare C:\... paths when Url::parse() fails
• Compare the "Open Warp Here" flow (Windows 10: "Open Warp Here" opens 2 instances. #6143) vs "Open Warp in new tab" to see if they share the same path-passing mechanism

Additional context

• Related issue: Linux: Launching Warp through "Open in Terminal" in context menu opens it in $home path instead of context path #6665 (same bug on Linux — context menu "Open in Terminal" opens at $HOME)
• Related issue: Windows 10: "Open Warp Here" opens 2 instances. #6143 (Windows "Open Warp Here" opens 2 instances — different bug but same shell extension surface)
• This is filed as a bug report; full investigation likely requires a Windows development environment to trace the shell extension → URI handler flow