vscode-go
vscode-go copied to clipboard
go binary not found even though PATH and even GOROOT is maintained correctly - plugin not working with latest 1.24 version
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
- Run
go versionto get version of Go from the VS Code integrated terminal.- go version go1.24.0 darwin/arm64
- Run
gopls -v versionto get version of Gopls from the VS Code integrated terminal.- Build info ---------- golang.org/x/tools/gopls v0.17.1 golang.org/x/tools/[email protected] h1:Mt/DSfnnSe3dyf6MH/dZZ0iww+viHNhAFc4rEYDiOAw= github.com/BurntSushi/[email protected] h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs= github.com/google/[email protected] h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI= golang.org/x/exp/[email protected] h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ= golang.org/x/[email protected] h1:D4nJWe9zXqHOmWqj4VMOJhvzj7bEZg4wEYa759z1pH4= golang.org/x/[email protected] h1:fEo0HyrW1GIgZdpbhCRO0PkJajUS5H9IFUztCgEo2jQ= golang.org/x/[email protected] h1:TCDqnvbBsFapViksHcHySl/sW4+rTGNIAoJJesHRuMM= golang.org/x/[email protected] h1:gK/Kv2otX8gz+wn7Rmb3vT96ZwuoxnQlY+HlJVj7Qug= golang.org/x/[email protected] h1:kgwdasJRsdDWYgWcEgMF424DiXwwXHSb3V8xVTi//i8= golang.org/x/[email protected] h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I= honnef.co/go/[email protected] h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I= mvdan.cc/[email protected] h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU= mvdan.cc/xurls/[email protected] h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8= go: go1.24.0
- Run
code -vorcode-insiders -vto get version of VS Code or VS Code Insiders.- 1.97.2 e54c774e0add60467559eb0d1e229c6452cf8447 arm64
- Check your installed extensions to get the version of the VS Code Go extension
- Version 0.44.0
-
Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) >
Go: Locate Configured Go Toolscommand.
Share the Go related settings you have added/edited
Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.
"go.gopath": "/Users/d070210/go",
"go.goroot": "opt/homebrew/Cellar/go/1.24.0/libexec",
"go.testTags": "integrationtesting",
Describe the bug
My local setup always worked but somehow it stoped. Now I can run ginkgo tests but my intellisence and everything within vscode doesnt work. go commands work like a charm. GOROOT and PATH contain everything needed
Steps to reproduce the behavior:
- Go to 'start vscode'
- See error
where go command results in: "/opt/homebrew/Cellar/go/1.24.0/libexec/bin/go"
Screenshots or recordings
If applicable, add screenshots or recordings to help explain your problem.
zshrc:
export GOPATH=$HOME/go
export GOROOT=/opt/homebrew/Cellar/go/$(ls /opt/homebrew/Cellar/go)/libexec
export PATH=$PATH:$GOPATH/bin
export PATH=$PATH:$GOROOT/bin
okay after downgrading again to version 1.23.6 everything worked again. Seems like the plugin is not working with latest stable version!
@rufreakde the plugin does work with the latest version of Go. The version of Go should not matter here, as the error is saying that the Go binary itself could not be found. Can you try upgrading again? I suspect that the downgrade may have adjusted your PATH.
@rufreakde the plugin does work with the latest version of Go. The version of Go should not matter here, as the error is saying that the Go binary itself could not be found. Can you try upgrading again? I suspect that the downgrade may have adjusted your PATH.
My colleagues also upgraded and it was the same issues we are currently blocked upgrading to the newest go version. We checked the path several times I dont know why but with the new version it does not find the relevant binaries. With old version it does.
I also checked if the path is correctly configured with newest version ran go program and commands from terminal and also ran our tests with ginkgo (which also reads go from path) all workes great but the plugin just says its not installed. Reinstalling plugin updating vscode and restarting MAC did not help.
So we all 3 backported to version 1.23.6 instantly fixes itself (after adjusting the path manually again)
also in my original post you see wher go was installed from my command
where go # command results in: "/opt/homebrew/Cellar/go/1.24.0/libexec/bin/go"
Any updates seems like other people 👍 the issue as well.
CC @h9jiang, who may be able offer additional debugging advice. I agree that it seems like the Go binary should have been found.
I have a similar issue
~/Documents/dym/d-dymension git:(danwt/hyperlane-pfm) which go
/opt/homebrew/bin/go
~/Documents/dym/d-dymension git:(danwt/hyperlane-pfm) /opt/homebrew/bin/go env
# it works!
...
In vscode
2025-05-16 11:59:26.390 [info] Failed to run '/opt/homebrew/bin/go env' (cwd: /Users/danwt/.dymension): Error: spawn /opt/homebrew/bin/go ENOEN
I've had this as well, I install go with homebrew. The workaround I have for now is to add the following to the VSCode settings:
"go.goroot": "/opt/homebrew/Cellar/go/1.24.4/libexec"
Which is obviously not ideal as the version is in the path so as I upgrade Go this will need to change. If I remove this line from my settings the issue reappears
Running which go gets me: /opt/homebrew/bin/go
go env
AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='c++'
GCCGO='gccgo'
GO111MODULE='on'
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN='/Users/tomfleet/go/bin'
GOCACHE='/Users/tomfleet/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/tomfleet/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/y_/1g9jx9bd5fg9_5134n1dtq1c0000gn/T/go-build2883917020=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/Users/tomfleet/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/tomfleet/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.24.4/libexec'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/tomfleet/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.24.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'
Go Related VSCode Settings
{
"go.addTags": {
"promptForTags": false,
"tags": "json",
"transform": "camelcase"
},
"go.alternateTools": {
"customFormatter": "golangci-lint"
},
"go.diagnostic.vulncheck": "Imports",
"go.formatFlags": [
"fmt",
"--stdin"
],
"go.formatTool": "custom",
"go.goroot": "/opt/homebrew/Cellar/go/1.24.4/libexec",
"go.lintFlags": [
"--path-mode=abs",
"--fast-only"
],
"go.lintTool": "golangci-lint",
"go.toolsManagement.autoUpdate": true,
"go.useLanguageServer": true,
"gopls": {
"analyses": {
"shadow": true
},
"formatting.gofumpt": true,
"ui.codelenses": {
"gc_details": true,
"generate": true
},
"ui.completion.usePlaceholders": false,
"ui.documentation.hoverKind": "FullDocumentation",
"ui.navigation.symbolScope": "workspace",
"ui.semanticTokens": true
}
}
I have found something interesting. It looks like the extension (or VSCode itself?) isn't sourcing my environment variables correctly when launched via the dock icon or via a command launcher like raycast.
If I remove the go.goroot setting above to re-trigger the problem then launch VSCode via raycast or the dock icon I get the error notice.
If however, I launch VSCode from within my terminal it all works perfectly. Presumably in the latter case, VSCode is inheriting the environment variables from the enclosing shell that has $GOROOT set.
But when launched "standalone" it does not. This is despite me having my shell set as the login shell which as far as I'm aware should mean those environment variables are inherited by everything?
vscode-go does not have its own environment variable logic, it just uses the environment variables that it was launched with (aka it inherits them from VSCode itself).
If however, I launch VSCode from within my terminal it all works perfectly. Presumably in the latter case, VSCode is inheriting the environment variables from the enclosing shell that has
$GOROOTset.
That's exactly what's happening.
But when launched "standalone" it does not. This is despite me having my shell set as the login shell which as far as I'm aware should mean those environment variables are inherited by everything?
It doesn't matter what your login shell is, the GUI/desktop environment does not care. When macOS and Linux initialize the desktop environment, environment variables that are set by an RC file (.bashrc, .zshrc, etc) are ignored because the OS does not execute your login shell and thus RC files are not executed. Your login shell and RC files are only executed when you open up a CLI such as Terminal or a virtual TTY (on Linux).
If you want environment variables to be set for the desktop environment, you must explicitly set that up. Doing this in macOS is a problem. There are ways to set environment variables though they've changed drastically over the years. However PATH gets special treatment and most or all of the solutions for setting environment variables don't work for PATH. The situation is better in Linux. If you're using systemd, the best solution seems to be ~/.config/environment.d/*.conf; Arch's environment variables wiki page discusses many other options, but keep in mind that anything using RC files will not apply to GUI/desktop apps (unless you use a shell to launch them).
Caveat: According to the Arch wiki, some display managers do read from RC files like .bash_profile, .zprofile, .zlogin, etc. But if you're using systemd it seems safer to stick with ~/.config/environment.d/*.conf, especially since the above may only be true for Xorg sessions and not Wayland sessions.
@h9jiang Given that macOS is such a PITA about configuring PATH for the desktop environment, I think it may make sense to add some kind of special logic for environment variables. The cleanest solution may be to simply run env using a shell.
Thanks for the detailed response! I'm on a mac sadly so have had some success with system wide env vars using launchctl and plist files but as you said, setting $PATH this way just does not seem to work at all.
Anyone have any idea why this would have started happening recently? (last 1 - 2 months). My system, VSCode, shell, Go etc. has not changed at all in that time and before this issue arose I was using Go and VSCode daily and it all worked just fine
No clue. Though given that Go now has it's own version management (go will download newer versions of the toolchain when needed) I think it would be easier to manually install from https://go.dev/dl and then let Go handle version management moving forward.
Hi @rufreakde, it is not recommended to set GOROOT unless you are very confident that the Go binary and the Goroot will work. In general, we don't want users to set GOROOT, this only introduce problem than convenience. One of the reason is, the Go binary is determined by the PATH, the std library is determined by the GOROOT. If you set GOROOT env var, you may end up with having a Go 1.23 and GOROOT pointing to the Go 1.24. Because Go binary have GOROOT baked into it, so please let Go itself to determine which GOROOT to use. The GOROOT baked into the binary knows which std library it should use.
To avoid confusion, the "go.goroot" configuration in vscode-go setting, is a configuration for user to Specifies the GOROOT to use when no environment variable is set.. This is a way for user to tell the extension, which Go should the extension use.
For @FollowTheProcess, I understand your frustration here. I tried a few approach locally and you can give it a try when you have time. I might not be able to offer you everything you are asking and there should be some improvement we can do.
First, make sure that you did not select anything explicitly in vscode-go extension, running command Go: Choose Go Environment and then choose the option "Clear Selection"
What I have done locally is, I add /opt/homebrew/bin to PATH and make sure it is always the first dir that have go. So in terminal, I can do
/opt/homebrew/bin/ [stable] which go
/opt/homebrew/bin/go
/opt/homebrew/bin/ [stable] go version
go version go1.23.11 darwin/arm64
/opt/homebrew/bin/ [stable] brew unlink go && brew link --force [email protected]
Unlinking /opt/homebrew/Cellar/go/1.24.5... 0 symlinks removed.
Unlinking /opt/homebrew/Cellar/[email protected]/1.23.11... 2 symlinks removed.
Linking /opt/homebrew/Cellar/go/1.24.5... 2 symlinks created.
/opt/homebrew/bin/ [stable] go version
go version go1.24.5 darwin/arm64
/opt/homebrew/bin/ [stable] brew unlink go && brew link --force [email protected]
Unlinking /opt/homebrew/Cellar/go/1.24.5... 2 symlinks removed.
Linking /opt/homebrew/Cellar/[email protected]/1.23.11... 2 symlinks created.
If you need to have this software first in your PATH instead consider running:
echo 'export PATH="/opt/homebrew/opt/[email protected]/bin:$PATH"' >> ~/.zshrc
/opt/homebrew/bin/ [stable] go version
go version go1.23.11 darwin/arm64
/opt/homebrew/bin/ [stable] which go
/opt/homebrew/bin/go
So I can switch between Go versions in homebrew by unlink and re-link go to different version.
Then, in vscode-go, I did not set anything related to go.gopath, go.goroot. Exit vscode and re-launch vscode. The vscode-go should pick up the go binary from the PATH. You can check which go being selected by running command Go: Choose Go Environment, the first option under Locally Discovered is the Go being selected. But not click anything just Esc to cancel.
During your local development, you may want to switch between go versions. To do that, you just use the brew to unlink and relink it.
/opt/homebrew/bin/ [stable] go version
go version go1.23.11 darwin/arm64
/opt/homebrew/bin/ [stable] brew unlink go && brew link --force [email protected]
Unlinking /opt/homebrew/Cellar/go/1.24.5... 0 symlinks removed.
Unlinking /opt/homebrew/Cellar/[email protected]/1.23.11... 2 symlinks removed.
Linking /opt/homebrew/Cellar/go/1.24.5... 2 symlinks created.
/opt/homebrew/bin/ [stable] go version
go version go1.24.5 darwin/arm64
Then reload the vscode by calling Developer: reload window, and you can try checking the Go: Choose Go Environment again. Check if the first option locally found is pointing to the right version.
Why can't vscode-go just pickup the new version, 1.24.5 after I switch from 1.23.11 to 1.24.5?
Vscode-go have some caching logic means it will only try to find the go once. Once it found it, it remembers it in cache and reuse it everytime. This logic is kind of questionable (but maybe it exist for a good reason, it is here for several years now). I can't really figure out why it is here. But a reload window restart the extension so vscode-go have to re-evaluate the go.
If we get rid of the caching mechanism, the extension will try to re-evaluate the go every time it runs, this maybe solve your problem but may introduce other problems (the original intention of this caching mechanism). An on-demand go binary lookup would be a better solution but the extension may not have a mechanism to watch for a symbolic link change.
Why am I seeing go version in go mod cache?
I think this is related to the go auto-upgrade. If my home brew is pointing to 1.23.11 and my workspace require a 1.24+, then the Go: Choose Go Environment will auto upgrade. But if you switch again from 1.23.11 to 1.24.5 and reload, it should point to the 1.24.5 after reload.
As commented in issue #971, sometimes, "go.goroot" is helpful if you want to have a per-workspace configuration. You can do that by creating a .vscode dir in your workspace.
If this does not work for you or this is not what you are looking for, let me know.
~The problem appears to no longer be present for me (having changed absolutely nothing 😂) I guess a release somewhere (vscode itself, gopls ?) has fixed it either intentionally or unintentionally~
Nope, got too excited it appeared to work but then on restart it was the same!
What I have done locally is, I add /opt/homebrew/bin to PATH and make sure it is always the first dir that have go
I have this also, VSCode respects this when I launch using the code cli from within my terminal. But if I launch via the Dock icon or via raycast it does not (but this used to work just fine)
running command Go: Choose Go Environment and then choose the option "Clear Selection"
This appears to have done the trick! I cleared then restarted VSCode and selected the right Go (it was listed as "locally discoverable") then it seemed to work! 🎉
Thanks. I'm glad you find the command useful.
This appears to have done the trick! I cleared then restarted VSCode and selected the right Go (it was listed as "locally discoverable") then it seemed to work!
This command I believe is finding all available go from your PATH and a few other known dir, list them. The first one shows up is the go that vscode-go is using right now. (That's considered as the default option).
If you set Go from this command, vscode-go will honor your selection until you Clear Selection or Choose another one.
If you simply clear the selection, vscode-go will infer which go you want to use from your environment variable like GOROOT and PATH, also consider the configuration go.goroot in your vscode setting. The go being selected will show up as the first option under "locally discoverable".
Vscode-go have some caching logic means it will only try to find the go once. Once it found it, it remembers it in cache and reuse it everytime.
Just to make sure you don't encounter this in the future, if you ever upgrade or downgrade your go versions using either homebrew or go installer, try clear the selection and reload the window. This will force vscode-go to look at your PATH again and try to find all available Go in your PATH and known dir. So you can select the right Go from this command.
Do you think we can close this issue? You can re-open if you ever encounter this again and find the instructions above not helping.
I do still get the issue on fresh starts it seems.
The following steps produce no error and work as expected:
- Open VSCode from the terminal using
code <dir>(this works out of the box because it inherits$PATHfrom the enclosing environment) - Use the Go: Choose Go Environment command to clear and then re-select the Go binary (in
/opt/homebrew/Cellar/go/<version>/libexec/bin/go) - Next time I open VSCode either via the
codecommand or via the Dock/Raycast etc. for the same project this works no problem
If however I open a different project via the Dock or Raycast after having done the above steps I'm again met with:
Failed to find the "go" binary in either GOROOT() or PATH(/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin).
Check PATH, or Install Go and reload the window. If PATH isn't what you expected, see https://github.com/golang/vscode-go/issues/971
When I try the Go: Choose Go Environment command in this state I get:
The $PATH shown in the first error message is missing a lot of entries, I've not changed anything in my system setup or VSCode settings in the time in which this has started happening, the exact same setup has worked for me for months if not years before this started happening so I'm a little lost 🤷🏻♂️
Use the Go: Choose Go Environment command to clear and then re-select the Go binary
You shouldn't use it to re-select the Go binary. I thought you want the vscode-go to infer which go from PATH. With instructions I provided previuosly, I was able to switch go version using brew and reload window so the go extension will catch up the new version that I just switched to.
If the intention is letting vscode-go to infer the go from your path, please keep it de-selected.
Next time I open VSCode either via the code command or via the Dock/Raycast etc. for the same project this works no problem
I was trying to re-produce this behavior again using a new mac laptop. I launch vscode from the dock, if I close the window and re-open, the error (can not find go in path) shows up. if I close the window and then quite, re-open, the error disappear.
The difference is, for closing the window, I simply click the red cross button on the top left. And the PATH printed by vscode-go error is missing the /opt/homebrew/bin
When I quit the vscode, I right clicked the vscode icon in the dock and click quit. When I re-open the same workspace, the error showed up previously disappears.
When quit vscode, the small dot next to the vscode icon disappears. When closing the vscode window, the small dot next to the vscode icon still persists.
I have tried to re-produce this issue multiple times but all failed. Maybe I'm doing it wrong. If the above instructions do not help, please reach out to me through gophers slack and we can set up a quick meeting to try it out.
bash-3.2$ ls ~/.bash*
/Users/me/.bash_history /Users/me/.bash_profile~
/Users/me/.bash_profile
bash-3.2$ cat ~/.bash_profile
export PATH="/opt/homebrew/bin:$PATH"
You shouldn't use it to re-select the Go binary. I thought you want the vscode-go to infer which go from PATH
Sorry I wasn't clear, I've done both and the only thing that fixes it from within a session is picking the path.
I launch vscode from the dock, if I close the window and re-open, the error (can not find go in path) shows up. if I close the window and then quite, re-open, the error disappear.
I did exactly this and the error shows up for me regardless :(
The only thing that reliably gets rid of the error is:
- Setting
go.gorootin the settings - Launching VSCode via the command line
Which leads me to believe it's just not looking up my $PATH correctly when not launched from within my shell. I'll do a bit more digging to see if I can figure out why not and whether it's something to do with my local setup but everything from within a shell works fine
I'm using nushell if that's relevant? But I have $env.PATH configured properly:
My problem I think is exactly as per the linked issue in the error message: https://github.com/golang/vscode-go/issues/971 it's just not finding the right $PATH
AFAIK on macOS you can’t control PATH for processes launched via the GUI (i.e. not launched from the CLI).
Issue solved it self in recent version of go / go plugin/ and vscode and brew installation...
Please reopen if this issue persists for others.