Make gh path configurable

[psrpinto]

I was getting the following error when running the extension:

12:05:48 [git-jump] Failed Automattic: Command failed: /bin/zsh -lc 'gh repo list '\''Automattic'\'' --limit 1000 --json name,url,description,isArchived,visibility'
zsh:1: command not found: gh

Summary

• Resolves the gh binary by probing the filesystem instead of relying on the shell PATH: it checks the gh CLI Path preference first (default /opt/homebrew/bin/gh), then the standard Homebrew locations (/opt/homebrew/bin/gh, /usr/local/bin/gh), and finally bare gh so the shell can resolve it — using the first that works.
• Adds a gh CLI Path preference so users whose gh lives somewhere unusual (nix/mise/asdf, etc.) can point the extension at it directly.
• A wrong, empty, or stale path is no longer fatal — any standard Homebrew install is picked up automatically with no configuration.

Why

The extension previously relied on gh being discoverable via the shell's PATH. On my machine /opt/homebrew/bin is only added to PATH by an oh-my-zsh plugin that runs in interactive shells, so the non-interactive shell the extension spawns couldn't find gh. Coaxing it out of an interactive login shell (-ilc) was fragile — it also let .zshrc stdout noise corrupt JSON parsing — and slower.

Probing the filesystem for the binary sidesteps PATH resolution entirely: the shell stays a plain login shell (-lc), JSON.parse works directly on stdout, and standard installs need no configuration.

Known limitation

Changing the gh CLI Path preference does not take effect until the extension is reloaded — getPreferenceValues() appears not to pick up changes within a running process. In practice this rarely matters, since standard Homebrew installs are found automatically without setting the preference at all.

Test plan

• Trigger a repo fetch with gh at a standard Homebrew location and no preference set — confirm it succeeds
• Set a custom path (e.g. /usr/local/bin/gh on Intel) and confirm it works
• Confirm the error toast is shown (not a crash) when gh cannot be found at any location

[Copilot]

Pull request overview

This PR adjusts how the Raycast extension shells out to gh so the user’s interactive zsh config is loaded (improving PATH resolution), and adds a workaround to parse gh JSON output even if shell startup prints extra lines.

Changes:

• Switches shell invocation from login-only to interactive+login when running gh (-lc → -ilc).
• Adds a stdout “JSON array extraction” step before JSON.parse to tolerate non-JSON noise emitted by shell init files.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[PanosSynetos]

Thank @psrpinto - I tested this and it works. Although I'm not a big fan of the JSON regex, I understand why we need to do it.

If you have any other suggestion, happy to hear it otherwise, I'll go ahead and merge this in a couple of hours

[psrpinto]

@PanosSynetos I'm not a huge fan of that either, I was planning on taking a look after I saw copilot's comment but ran out of time yesterday. Let me take another look.

[psrpinto]

I took a deeper look into what was going on, and I realized the problem is that, in my machine, /opt/homebrew/bin is being added to the PATH by an oh-my-zsh plugin, which only runs when .zshrc is loaded, which only happens in interactive shells.

So that was the root of the problem in my case, but there could be all sorts or scenarios that result in gh not being added to the PATH. Also, loading an interactive shell could be opening a can of worms, and it would probably make things slower.

So I figured a better solution would be to not rely on it being in the PATH, and instead reference it directly. So I changed the approach to instead make the path configurable through an extension setting, defaulting to where it is typically found when installed with homebrew. This removes the need to use an interactive shell.

Let me know if this makes sense. The PR description has been updated and the commits of the previous approach were dropped.

[PanosSynetos]

Hey @psrpinto - It doesn't seem to work as expected. When I change the path in settings, it doesn't get the new path. See screencast

I have a wrong path, it initially fails, I edit the path to the correct one, and unless I reload the extension, it doesn't get the new path from settings, but gets what it initially loaded.

We can sync if you want

Monosnap.screencast.2026-05-04.10-26-41.mp4

[PanosSynetos]

Any luck with this PR @psrpinto ?

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

[psrpinto]

@PanosSynetos Since your review, the key change is that the gh CLI Path preference is no longer the only way the extension finds gh. It now probes the filesystem: the preference first, then the standard Homebrew locations (/opt/homebrew/bin/gh, /usr/local/bin/gh), and finally bare gh. So a wrong or stale path is no longer fatal, for a standard Homebrew install, gh is found automatically without setting the preference at all.

That indirectly addresses what you ran into: since most setups don't need the preference, there's usually nothing to edit-and-reload in the first place. On the reload behavior itself — where editing the preference only takes effect after a reload — I couldn't get it to update from within a running command, only after a reload. I haven't pinned down why for certain: it looks like getPreferenceValues() doesn't pick up changes within a running process, but I'm not sure whether that's expected Raycast behavior, a dev-mode quirk, or something on our side.

I think know everything works. Let me know what you think.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.