Skip to content

Fix DAP binary resolution for remote worktrees - #94

Merged
MrSubidubi merged 3 commits into
zed-extensions:mainfrom
TateWalker:main
Aug 28, 2026
Merged

MrSubidubi merged 3 commits into
zed-extensions:mainfrom
TateWalker:main

Conversation

@TateWalker

@TateWalker TateWalker commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Problem

get_dap_binary passed raw binary names ("flutter", "dart", "fvm")
as commands without resolving them against the host's PATH. WASM extensions
cannot read $PATH directly, so the debug adapter failed to launch on remote
(SSH) worktrees.

Fix

Resolve binary paths using worktree.which(), which works correctly on both
local and remote worktrees. This is consistent with how language_server_binary
already resolves the dart binary.

Related Issues

@cla-bot

cla-bot Bot commented Jun 12, 2026

Copy link
Copy Markdown

We require contributors to sign our Contributor License Agreement, and we don't have @TateWalker on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

@TateWalker

Copy link
Copy Markdown
Contributor Author

@cla-bot check

@cla-bot cla-bot Bot added the cla-signed label Jun 12, 2026
@cla-bot

cla-bot Bot commented Jun 12, 2026

Copy link
Copy Markdown

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

@TateWalker

Copy link
Copy Markdown
Contributor Author

@MrSubidubi checking to see if anything on this needs changing

@TateWalker

This comment was marked as spam.

@MrSubidubi MrSubidubi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the brief description above, but would you mind explaining how this prevents the auto-install and also on the $PATH-part? Does this happen because if we boot the remote server CLI, we do not load the full user path and hence need the which-API which does just that?

@TateWalker TateWalker left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, I meant that when I open Zed, it auto-replaces my custom dart extension (this one) with the official one, rolling back my changes. I then have to uninstall and reinstall my dev extension to resume remote debugging work. That issue isn't related to this PR, just stating a separate concern.

On the $PATH question: yes, exactly. The remote server process may not load the full login shell environment, so $PATH can be incomplete. WASM extensions are also sandboxed and can't reliably read environment variables like $PATH directly via std::env::var. worktree.which() resolves binaries through the host process' environment context, which works correctly regardless of whether the worktree is local or remote. This is how the language server binary already handled it:

// src/dart.rs line 37
if let Some(path) = worktree.which("dart") {

@TateWalker
TateWalker requested a review from MrSubidubi July 30, 2026 02:06

@MrSubidubi MrSubidubi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, let's go with it. Sorry for stalling this for so long, and thank you so much!

@MrSubidubi
MrSubidubi merged commit ef73f54 into zed-extensions:main Aug 28, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants