zed-industries/zed · error

cannot find app bundle containing {cli_path:?}

Error message

cannot find app bundle containing {cli_path:?}

What it means

On macOS, the CLI's locate_bundle() walks up from the canonicalized path of the running executable looking for a directory with an .app extension. It errors when the binary is not inside any application bundle, because the CLI needs the bundle (and its Info.plist) to launch the right Zed app.

Source

Thrown at crates/cli/src/main.rs:1309

        #[serde(rename = "CFBundleShortVersionString")]
        bundle_short_version_string: String,
    }

    enum Bundle {
        App {
            app_bundle: PathBuf,
            plist: InfoPlist,
        },
        LocalPath {
            executable: PathBuf,
        },
    }

    fn locate_bundle() -> Result<PathBuf> {
        let cli_path = std::env::current_exe()?.canonicalize()?;
        let mut app_path = cli_path.clone();
        while app_path.extension() != Some(OsStr::new("app")) {
            anyhow::ensure!(
                app_path.pop(),
                "cannot find app bundle containing {cli_path:?}"
            );
        }
        Ok(app_path)
    }

    impl Detect {
        pub fn detect(path: Option<&Path>) -> anyhow::Result<impl InstalledApp> {
            let bundle_path = if let Some(bundle_path) = path {
                bundle_path
                    .canonicalize()
                    .with_context(|| format!("Args bundle path {bundle_path:?} canonicalization"))?
            } else {
                locate_bundle().context("bundle autodiscovery")?
            };

            match bundle_path.extension().and_then(|ext| ext.to_str()) {

View on GitHub (pinned to bc538def45)

Solutions

  1. Symlink the bundled CLI instead of copying it: `ln -s /Applications/Zed.app/Contents/MacOS/cli /usr/local/bin/zed`
  2. Reinstall Zed from the official .dmg so the CLI stays inside the bundle
  3. Verify with `readlink -f $(which zed)` that the resolved path ends in `.app/Contents/MacOS/cli`

Example fix

# before (copied binary, bundle walk fails)
cp /Applications/Zed.app/Contents/MacOS/cli /usr/local/bin/zed

# after (symlink resolves back into the bundle)
ln -s /Applications/Zed.app/Contents/MacOS/cli /usr/local/bin/zed
Defensive patterns

Strategy: validation

Validate before calling

# verify the CLI resolves inside a bundle before use
resolved=$(readlink -f "$(command -v zed)")
case "$resolved" in
  *.app/Contents/MacOS/*) ;;
  *) echo "zed binary is outside an app bundle: $resolved" >&2; exit 2 ;;
esac
zed "$@"

Prevention

When it happens

Trigger: Running a `cli`/`zed` binary that was copied out of Zed.app, moved to /usr/local/bin as a real file instead of a symlink, or executed from a build target directory outside a bundle.

Common situations: Homebrew or manual installs where the binary was copied rather than symlinked; developers running target/release/cli from a source checkout; CI runners invoking a standalone binary.

Related errors


AI-assisted analysis of zed-industries/zed@bc538def45 (2026-08-16). Data as JSON: /api/errors/ad5db427e41b38b7. Report an issue: GitHub.