Error opening .command file

[Jackie-Tang]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Running the open launchPackager.command command results in an error: "Language support is unavailable for this file type."
This issue appeared after upgrading Warp; the previous version from February 2026 was able to run.

To reproduce

launchPackager.command file content：
#!/usr/bin/env bash
clear
THIS_DIR=$(dirname "$0")
pushd "$THIS_DIR"
source ./packager.sh
echo "Process terminated. Press to close the window"
read

run open launchPackager.command

Expected behavior

No response

Screenshots, videos, and logs

Operating system (OS)

macOS

Operating system and version

MacOS 15.6.1

Shell Version

zsh 5.9 (arm64-apple-darwin24.0)

Current Warp version

v0.2026.04.22.08.46.stable_03

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@captainsafia

You can view the triage session on Warp.

Here's what I found while triaging this issue:

This looks like Warp is opening the .command script as a text file in the editor instead of executing it. A likely workaround is to run it directly from the file's containing directory with bash launchPackager.command or ./launchPackager.command.

Maintainer details

I concluded that macOS .command scripts opened via open appear to be routed into Warp's code editor as plain text instead of being executed, leading the LSP footer to show an unsupported-language message..

Initial triage

Summary: Running open launchPackager.command on macOS appears to open the .command file in Warp's code editor instead of executing it as a shell script; the visible error is the editor/LSP footer saying the file type has no language support.

Observed symptoms:

• open launchPackager.command in Warp shows Language support is unavailable for this file type.
• The report includes a screenshot, macOS 15.6.1, zsh 5.9, and Warp v0.2026.04.22.08.46.stable_03.
• The file content is a plain bash script with a .command extension.

Code evidence:

• app/src/uri/mod.rs handles file:// URLs by opening files in Warp's editor when path.is_file() && is_file_openable_in_warp(&path).is_some() is true, before the fallback path that opens a terminal session and calls execute_file.
• app/src/util/openable_file_type.rs returns Some(OpenableFileType::Text) for non-binary files that are not Markdown or recognized code, which likely includes plain-text .command scripts.
• crates/lsp/src/config.rs maps only specific source-code extensions to LanguageId; .command is not mapped.
• app/src/code/footer.rs displays Language support is unavailable for this file type when the editor has no LSP language for the opened file.

Likely root cause: The .command file is being classified as a generic openable text file and routed to the editor, so Warp never reaches the intended fallback that would execute the file in a terminal session. The footer message itself is likely a secondary symptom of opening an unsupported extension in the editor rather than the primary failure.

Reproducibility: Medium. The provided steps and code path are plausible and concrete, but the behavior may depend on macOS Launch Services/default-app association for .command files and the exact previous working Warp build is not provided.

Suggested routing: area:editor-notebooks, os:mac. Primary code owner candidate is @seemeroland for file URL routing, with @kevinyang372 for the editor/LSP footer behavior.

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

Powered by Oz

[anshul-garg27]

Opened #9345 for this. Root cause: language_by_filename in crates/languages/src/lib.rs matches sh | zsh | bash for shell but not command, so opening a .command file falls through to None and the editor footer renders "Language support is unavailable for this file type". One-line addition to the match arm plus a regression test.

[Jackie-Tang]

已为此问题创建了#9345language_by_filename 。根本原因：匹配shell 但不匹配crates/languages/src/lib.rs，因此打开文件时会跳转到其他路径，编辑器底部会显示“此文件类型不支持该语言”。只需在匹配规则中添加一行代码并添加回归测试即可。sh | zsh | bash``command``.command``None

When will it be released?