cmd/go: can't invoke a tool with -modfile within a workspace

[anuraaga]

Go version

go version go1.24.3 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='c++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/anuraag/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/anuraag/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/vx/38td0k79201f9zn_myzbqx_40000gn/T/go-build645842018=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/Users/anuraag/git/go-build/go.mod'
GOMODCACHE='/Users/anuraag/go/pkg/mod'
GONOPROXY='github.com/tetrateio/*'
GONOSUMDB='github.com/tetrateio/*'
GOOS='darwin'
GOPATH='/Users/anuraag/go'
GOPRIVATE='github.com/tetrateio/*'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.24.3/libexec'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/anuraag/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.24.3/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.24.3'
GOWORK='/Users/anuraag/git/go-build/go.work'
PKG_CONFIG='pkg-config'

What did you do?

go tool -modfile build/tools/golangci-lint/go.mod golangci-lint run -h

Note, go.work does not include ./build/tools/golangci-lint. build/tools/golangci-lint/go.mod contains single tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint and the dependencies added by go mod tidy.

What did you see happen?

go: -modfile cannot be used in workspace mode

What did you expect to see?

Tool runs normally. I would like to use separate mod files for tools to protect against dependency conflicts. Unfortunately, -modfile cannot be used in a workspace (#59996).

It does work if specifying GOWORK=off, but for tools that build Go code, such as golangci-lint (or perhaps opentelemetry-go-autoinstrumentation, etc), this causes the downstream tool invocation to inherit the variable and generally not work if the workspace settings are required to build the code. It seems like it should be possible to run tools with isolated modfiles within a workspace.

A couple of ideas

• Respect -modfile specifically for the tool command if the tool module is not in the workspace (my current issue is specific to tool but the same may apply to run instead of blocking the flag completely like now). IIUC cmd/go: reject the -modfile flag in workspace mode #59996 correctly, the corner case is specifically running a workspace module with the flag set and there wouldn't be problems for modules not defined in the workspace?

• Add a command line flag with the same semantics as GOWORK, e.g. go tool -gowork off -modfile tools/golangci-lint/go.mod run. This would allow configuring go tool without affecting the downstream invocation. Unfortunately, the best named -work flag is already taken.

[gabyhelp]

Related Issues

• cmd/go: reject the `-modfile` flag in workspace mode #59996 (closed)
• x/website: ref/mod still references the deleted -workfile flag #51838 (closed)
• cmd/go: workspace detected outside of workspace #51604 (closed)
• cmd/go: go work init won't create nested workspaces #53938
• x/tools/gopls: deprecate the "allowModfileModifications" setting #56570 (closed)
• cmd/go: default `-mod=vendor` behavior unexpectedly present in workspace mode #54130 (closed)
• cmd/go: workspace recursive add should skip malformed module definitions #51959
• cmd/go/internal/modload: reject the -modfile flag in workspace mode #60033 (closed)

Related Code Changes

• cmd/go: report a helpful error when there are no modules in workspace
• cmd/go/internal/modload: reject the -modfile flag in workspace mode

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}